The last of YaST?
The announcement
of the openSUSE Leap 16.0 beta contained something of a
surprise—along with the usual set of changes and updates, it
informed the community of the retirement of "the traditional YaST
stack
" from Leap. The YaST ("Yet another Setup Tool")
installation and configuration utility has been a core part of the
openSUSE distribution since its inception
in 2005, and part of SUSE Linux since 1996. It will not, immediately,
be removed from the openSUSE Tumbleweed rolling-release
distribution, but its future is uncertain and its fate is up to the larger
community to decide.
YaST has undergone a number of revisions and rewrites over the years. The original YaST was replaced by YaST2 in 2002, and the project was released as open source, under the GPLv2, in 2004. YaST features graphical and text-based user interfaces, so it can be used on the desktop or via the shell. "Setup Tool" undersells what YaST does by a significant margin. It is the system installer, used for both interactive and unattended installations. It is also a tool for software management and performs a wide variety of system-management tasks—including user management, security configuration, and setting up printers.
For many years, YaST was implemented in its own programming
language, YCP,
which was phased out and mostly
replaced with Ruby around 2013 as part of the YCP Killer
project. Currently, YaST is written in Ruby, with some of the
graphical stack written in C, as well as some legacy bits in Perl and
YCP. As the contributing page
for the project notes, it is a "complex system consisting of
several components and modules
". Each of YaST's functions, such as
managing users, installing software, and configuring security
settings, is implemented as a modules. The project's GitHub organization has more than
240 repositories.
The decision to move away from YaST was not well-advertised for such a major component of the distribution. On October 7, 2024, Josef Reidinger replied to a question about the YaST:Devel repository with information about plans to develop YaST for SUSE Linux Enterprise Server (SLES) 16. There was, at that time, little indication that SUSE developers were thinking about dropping YaST from SLE 16 or Leap.
There was a mention of a YaST "stack reduction
" in the
openSUSE Release
Engineering minutes for November 27. The minutes note that
YaST modules would be reconsidered on a "per use case
basis
". However, it also linked to a features ticket for
openSUSE LEAP opened by Luboš Kocman in October 2024 that
said SUSE's product management "do not want any YaST in SLES
16
". It seems unlikely that many openSUSE users or contributors
would have discovered this, however.
In January, Andreas Jaeger wrote a blog post about plans for SLES 16, which contained a short section saying that YaST was being put into maintenance mode, though it would continue to be fully supported for the life of SLES 15. According to the SUSE lifecycle page, general support for SLES 15 will end in 2031.
Agama and YaST replacements
Even though the SUSE team has been relatively quiet about the intent to retire YaST, the Agama installer project did foreshadow the move. In 2022, the YaST developers started working on a new installer under the provisional name D-Installer, and the project was eventually named Agama after a type of lizard. The stated goal of this work was to decouple the user interface from YaST's internals, add a web-based user interface that would allow remote installation of the distribution, and more. That work progressed well enough that Agama was tapped to replace YaST as the installer for openSUSE Leap 16's alpha release. LWN covered Agama's development in August 2024.
At the time, the team was open about the fact that YaST was showing its age. That was part of the reason that they embarked on a from-scratch effort to replace it as the installer. However, Agama was more limited in scope than YaST as an installer—it lacked support for some of the AutoYaST unattended deployment features, for example—and there was no indication that the team was considering replacing YaST altogether. All signs pointed to the two tools coexisting.
With the release
of Agama 10, the Agama team announced a standalone documentation
site for the project and started a new blog for Agama-related news
in October 2024 "to avoid confusion between YaST and
Agama
". Since then, the YaST blog has gone silent.
The Leap 16 beta announcement was the first public note
that explicitly stated the new direction for openSUSE. It said that
YaST had been retired in favor of Agama, Cockpit for system management,
and Myrlyn
(formerly YQPkg) for package management. (LWN looked at Cockpit in
March 2024.) The announcement also noted that YaST would
continue to be available in Tumbleweed but would no longer be
developed by SUSE. "If someone is interested in the maintenance of
YaST for further development and bugfixes, the sources are available
on github.
"
The future
I emailed several openSUSE contributors about the YaST retirement
and received a reply from Douglas DeMaio. He acknowledged that earlier
communication about Agama suggested that YaST would continue to be
used as a management tool, but "the pivot toward deprecation came as
Agama and Myrlyn progressed and were deemed more
future-proof
".
DeMaio said that there were a few reasons that the change is
happening in Leap 16. One is that Agama and Cockpit are
"modern, modular, and API-driven
" which are better suited to
multi-distribution environments that users are working in. Adopting Cockpit,
he said, "helps reduce fragmentation and brings alignment with
other Linux distributions
"; that will make life easier for developers
and users alike. The other is that YaST's code base is large and
complex, and it was decided it would be more practical to design a
new, modular structure from the ground up.
He said that no standalone announcements have gone out to the YaST
development list or openSUSE's Factory development list because YaST
still exists in Tumbleweed. It will be phased out slowly, and YaST
packages may be deprecated or picked up by the community "based on
interest, available maintainers, and whether there's a clear use case
or demand within the community to keep them alive
".
Absent any community effort to maintain YaST, it will likely degrade in place until it is removed entirely from Tumbleweed. Dominique Leuenberger said on the openSUSE Factory mailing list that there are already components that no longer work, and more are likely to break soon.
What's likely to hit a big nail in the coffin will be the next Ruby version update: we've seen every year that the update needed 'some work' on the YaST code base. Without anybody looking after it, there is a big chance things will break by then.
Ruby has one major release a year, on December 25. Thus, Tumbleweed users have more than six months before Ruby-related breakage starts to set in.
It would be hard to argue against SUSE's decision to move away from YaST in favor of more modern tooling. At one time, YaST was a selling point for the distributions—it provided a one-stop shop for system management and configuration that was user friendly. Now, however, much of its functionality is present in more modern tools like Cockpit or the configuration tools included with GNOME and KDE. It makes sense to adopt the healthy upstream projects rather than to continue to develop a distribution-specific tool that offers little functionality not found elsewhere.
But the lack of communication about its retirement, even though it was clearly being discussed behind closed doors last year, is unfortunate. If there are openSUSE community members passionate about maintaining YaST, they could have benefited from an early warning about YaST's deprecation. Perhaps openSUSE could take a cue from Fedora's change process, for example, to ensure that major changes are communicated early and the community is given an opportunity to weigh in. If there are no willing maintainers to be found, openSUSE Tumbleweed users would no doubt still appreciate clear communication about the change rather than a slow trickle of information.
YaST may have outlived its usefulness, but it served the SUSE community well for decades and made Linux more approachable for many users. It deserves a better sendoff than a slow fade into obscurity.
Posted May 12, 2025 15:23 UTC (Mon)
by troglobit (subscriber, #39178)
[Link] (10 responses)
Posted May 12, 2025 15:41 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
And SuSE always used to be KDE. That went a while back ... now YaST ... without a USP I suspect SUSE will struggle. Maybe they're struggling now, and that's why they're doing it, but there's plans for survival, and there's thrashing and drowning. Let's hope it's not the latter!
Cheers,
Posted May 15, 2025 9:35 UTC (Thu)
by tvannahl (subscriber, #134292)
[Link]
Recent developments and uncertainties in the Fedora family (CentOS burried, Successor unclear, OKD vs OpenShift) have sparked more interest into other distributions. Given SuSE has been picking up SELinux (finally), having an atomic OS strategy and now with the deprecation of YaST (my personal anti selling point) it is starting to sound more interesting to me.
Posted May 14, 2025 15:15 UTC (Wed)
by jmalcolm (subscriber, #8876)
[Link]
Honestly, with the current level of concern around US controlled organizations, “The Red Hat of Europe” may actually be a pretty successful shadow branding strategy.
With initiatives like Liberty Linux and OpenELA, a key part of SuSE’s plan is clearly to win over RHEL customers by letting them move to SuSE support while still retaining Red Hat software. If they want those customers to eventually migrate to SLE, reducing the impedance mismatch between the two offerings may actually make sense.
I remember when Steve Jobs rejoined Apple in 1997. They were almost bankrupt. He was immediately criticized for killing of key technologies like OpenDoc that set Apple apart. Then he brought Apple closer to Microsoft to the dismay of the faithful (even adopting Internet Explorer). Then Apple became the most valuable company in the world.
I am not predicting that future for SuSE. I really do not know much about them really. But sometimes these kinds of moves pay-off.
Posted May 15, 2025 10:34 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (6 responses)
The notion that there must be distro specific tools in order to be unique seems misguided to me and they don't really loose any control by moving to Cockpit. It's been so many years since I have seen anyone mention YaST as the reason to use SuSE. If later on they disagree they can always fork it or go in a different direction at any point same as they did with their own installer which was originally Cockpit based as well.
IIRC when OpenSUSE was launched originally, they just mass imported Fedora's packaging guidelines at one point but they are obviously not the same distro today. As an example, Fedora's Atomic OS relied on ostree and has moved towards bootc now. SuSE seems to be betting more on just use Btrfs filesystem snapshots. You can take non unique tools and configure it quite differently to have very different results if you wanted to but I am glad more distros are consolidating around using more of the same foundational tools. I hope at some point they use the same package manager and so forth. If anything the common tooling likely helps them win over some customers because of the ease of transition even in the enterprise space where they compete on support and services value instead of lock-in.
Posted May 15, 2025 21:16 UTC (Thu)
by sionescu (subscriber, #59410)
[Link] (4 responses)
You should talk more to the users. If you go on forums (reddit, etc...) you'll notice that Yast is still a major selling point.
Posted May 15, 2025 21:26 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
Talking to users is how I got the subjective impression I already have, more isn't helpful there. It would be much more useful if there is a survey of the users to see if Yast remains a major selling point. If it is, why hasn't anyone stepped up to help maintain it? Is it because Ruby is no longer as popular?
Posted May 16, 2025 6:28 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
Because users aren't programmers? That is the fundamental problem with Open Source - the assumption that users can fix their own problems. When users and programmers were the same people, when the tools/problems were stuff programmers used in their daily life, that was true.
Now that linux has spread far and wide (and some of us want to spread it even wider), the idea that users have the skills and/or desire to fix their own problems is laughable. If YaST broke for me, I wouldn't have a clue where to start, and I've been a DP guy my entire career ...
I use YaST because it's easy to use, I'm familiar with it, and if there were any problems I wouldn't have a clue how to fix it ...
I use gentoo because it forces me to learn things I wouldn't have a clue about.
If SuSE drops YaST, I don't know what I'd replace (SUSE) with. I don't like RH, I don't like Debian-based systems, gentoo is too complicated to support for other people - what else is there?
Cheers,
Posted May 16, 2025 12:58 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
Wasn't talking about users, projects like openSUSE has other non SUSE contributors but also users include programmers in any substantial Linux community. If a project is that popular as has been asserted, other people step up to maintain it. This happens all the time.
Posted May 26, 2025 0:37 UTC (Mon)
by jjs (guest, #10315)
[Link]
In fact, back when I was more involved in the advocacy side of things, I recommended that companies using F/LOSS set aside 10-50% of what they were spending on licensing to spend on desired bug fixes & improvements of the software. If the main developers weren't interested, or too overloaded with other work (sorry, your bug is #2,000 on our priority list, we're still working on the first 50 bugs), they could pay someone else to make the changes. They could then donate that back to the project to get it incorporated & not have to maintain out of tree changes.
Posted Jul 16, 2025 8:25 UTC (Wed)
by DeMus (guest, #178252)
[Link]
That is probably true, I can't confirm that. But for me, when I installed openSUSE Tumbleweed years ago, after the first boot I did an upgrade/update and after the second (re)boot I opened Yast and on the opening screen I would start at the top left module and work my way down, row by row to see if I needed to change a setting, add something, or whatever. In a very short time I would have finished doing that and knew I did not forget something, meaning in a short time I did a complete setup which worked fantastic. I, like probably many others did not mention that anywhere.
After having used Fedora's immutable distro Kinoite and later on Ublue's Aurora I am now working my way towards a new period of having an openSUSE distro on my laptop and because of the immutable versions I have used in the past 1-1/2 years I now would like to start using Kalpa. A Yast would be very welcome there.
Posted May 14, 2025 20:05 UTC (Wed)
by jengelh (guest, #33263)
[Link] (3 responses)
Programs were quite unapproachable at the time. Some would:
* not start without a config file at all (/usr/bin/X, /usr/bin/man)
These days, on the other hand, you can just run fdisk & mkfs from a rescue shell, put a bunch of files into it, and already have a working system on the next boot. The use case for yast is evaporating and that's not necessarily a bad thing.
Posted May 15, 2025 2:11 UTC (Thu)
by raven667 (subscriber, #5198)
[Link]
I don't think the use for config management UI is significantly less than before but the specific technology gets rebuilt as each generation has different preferences and the base line technologies evolve. A TUI/GUI like YaST was good back then, and there was Webmin as well, but now Cockpit might be a better fit for the way systems are built today, which isn't removing config management UI, just changing the tech stack around what is available and we'll maintained today
Posted May 15, 2025 8:51 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
Have you read today's "Brief Items" and the rant on accessibility? Sounds like "successfully running a rescue shell" is rapidly becoming a thing of the past for today's disabled users ...
Cheers,
Posted May 15, 2025 15:55 UTC (Thu)
by jengelh (guest, #33263)
[Link]
I can't relate to either of the two things. How hard could it be to pass init=/bin/sh console=ttyS0 to the kernel? (ignoring the drama with non-accessible bootloaders for now)
Posted Jun 20, 2025 14:25 UTC (Fri)
by OneOrTwo (guest, #177963)
[Link]
What's left of SuSE?
What's left of SuSE?
Wol
What's left of SuSE?
What's left of SuSE?
What's left of SuSE?
What's left of SuSE?
What's left of SuSE?
What's left of SuSE?
Wol
What's left of SuSE?
What's left of SuSE?
What's left of SuSE?
I have wondered so many times why no other distro would either use Yast or create its own implementation of it. Yes, nowadays there are a few other distro's who have something which, when you look at those programs with your eyes closed, look a bit like Yast.
Approachability of computer systems
* use of bespoke hardware that did not support autoconfig or only poorly so (stuff on ISA buses, and COM, LPT connected-devices)
* had or have complex, sometimes overly complex, config files (pppd/modem stuff, sendmail.cf, grub2)
* might not function as expected when "optional" index files were absent (thinking fc-cache)
Approachability of computer systems
Approachability of computer systems
Wol
Approachability of computer systems
Yast is the main reason I use openSUSE
We usually run GUI free and yast make this a breeze to work that way.
Cockpit is ok, not great. I use cockpit on many Linux systems, and it is not a Yast replacement. It is ok, works best on Redhat type distributions. But I find I need to SSH anyway to the host, Yast wins over Cockpit.
I have not looked a Myrlin but I hope it works in text mode. I think having one tool to do everything like Yast is the way to go. And I hope they support text mode like Yast.