To add: Despite of all the noise, there have been zero (0.000, NULL) efforts or attempts to actually start doing such a thing.
6 Likes
The naming has been unfortunate since the start of this millenium.
In the mid/late 1990s, there was YaST, the original NCurses (text) only version. In late 1999, YaST2 was started, with both an NCurses and a Qt (graphical) user interface. The old YaST (then explicitly dubbed YaST1) existed in parallel to YaST2 for some releases, then it finally faded away.
All the while there were simple shell wrappers that started YaST2 NCurses when you started just yast on the command line; and also aszast for those German users who hadn’t set up their keyboard correctly (German: QWERTZ vs. US QWERTY). But it was still YaST2, albeit in the NCurses version. But you could also start YaST2 Qt in a terminal window with yast2. Both were and are still YaST2.
Around 2003-2005, sloppiness set in, and the YaST2 project name was shortened to just YaST. But it was still YaST2; the old YaST1 was gone by then. And confusion reigned supreme; some stuff was named YaST2-something, some other stuff just YaST-something. You can still see from the GitHub repo names yast-storage-ng, yast-network vs. the package names yast2-storage-ng, yast2-network. The mess is all over the place.
What you all know as YaST since about 20 years is in reality all YaST2, either with the NCurses or with the Qt UI. But since there is neither a YaST1 (anymore) nor a YaST3, the number has become meaningless.
So please don’t introduce an artificial distinction between YaST as YaST2 NCurses and YaST2 as YaST2 Qt. That’s simply wrong.
I know, this is a typical German overengineering thing.
But hey, I am a German (software) engineer; I can’t help it. It’s in my genes. 
–
HuHa
(soon to be ex-) YaST2 developer
(no worries, I’ll continue Myrlyn and QDirStat)
8 Likes
Ain’t gonna happen. Nobody wants to spend the work, time and life energy.
If anybody would want to give it a try, there is all the know-how to learn, all the code to reverse engineer, all the overdue refactoring in so many areas. Those who could do it have run to the hills long ago; but you can still hear their screams of panic and anguish lingering in the air.
In particular the NCurses mode has always been the Great Obstacle to make the UI good; to get good usability and good looks. You can’t have 1968 VT-100 text terminal compatibility and a smooth UI that looks good at the same time. Chose one or the other; you can’t have both.
We had one single area where the Qt version was really superior to the NCurses version: The package manager (not even including the repo manager). The reason was that it’s completely different code: libyui-qt-pkg, written purely in C++/Qt, and libyui-ncurses-pkg, written purely in C++ using ancient NCurses libs.
This is why we have Myrlyn today: It’s that libyui-qt-pkg (YQPkg) code, heavily refactored, and the missing pieces (loading repos, doing the transaction, the whole repo management) added. And that was only possible because YQPkg didn’t use any libyui/libyu-qt code.
Doing the same with the NCurses version would mean dragging all that libyui, libyui-ncurses, libycp, liby2 code in. You don’t know what that is? Praise your lord. You don’t want to know. You don’t want to take the deep dive into that world that you’d need. It’s just one step away from medieval alchemy or even witchcraft. 
All the life energy that we had spent for all those years was largely wasted. It was mostly for the kewl kids who felt they had to show off by running yast sw_single (YaST2 NCurses with the single software selection) in an xterm (!), i.e. in a perfectly working X11 environment. Because coolness, not because need.
Even the IBM s/390 people at some point demanded they’d get the YaST Qt UI on their mainframe; and they had been a major argument to keep the NCurses UI around because mainframe users only have text terminals.
For those who really only can use a text terminal, there is always the command line with zypper and config files with your favorite editor.
2 Likes
Thank you @shundhammer for your contributions and hard work over the years! We will never forget. 
Perhaps it’ll be nostalgic moving forward… the days when Yast2 Ncurses was available and worked from your text terminal, and for headless servers. Made some sys-admin tasks easier for those new jr linux admins. But I digress.
We will adapt and overcome, or else die - the process of evolution in time. We will have to conform to the cockpit ways of life, along with some of the ways of German engineering.
No, it’s not. In the early stages, when it was still named “D-Installer”, they tried to make a Cockpit module for Agama, but that didn’t work out. Ever since it’s named Agama, it’s a standalone web application without any Cockpit parts.
1 Like
Will there be any public announcements from SUSE regarding “Cockpit, the easy way” Life without YaST in SUSE…?
I still feel it was a poor decision making from SUSE executive team to nuke YaST and the default installer all at the same time for the Leap 16.0 release. Huge change, huge Leap!
Feel 16.0 release is similar to what another distro is currently going through; as they’re treating users like cattle and beta testing the stable/LTS release…
Agama is not production ready, its a joke [IMHO], the developer(s) took a short survey to a small group of users and marched forward. The wave of impacts it has on long-term users and enterprise support. Changes mindset and thinking of those deploying SLES/OpenSUSE in their environment, makes them ask – why pick SUSE?
There is a subset of users who also pick their distro based on the installation experience; Torvalds himself has remarks on that regard.
1 Like
You would have to ask SUSE what their plans are.
But that isn’t really the point of this discussion here (nor are opinions about Agama or Cockpit). So let’s stay on topic here.
It would be better to collate desktop based alternatives to yast applications rather than this weird gas lighting that a remote tool is a replacement.
1 Like
Cockpit doesn’t have to be run as a remote tool. Just like the cupsd web UI it can be run locally and accessed from a browser on the same machine.
3 Likes
This Forum has some slight discrepencies.
This post is in the “leap-160” section. (not much here).
The majority of the “Leap 16” posts are in the “leap-16” category. Not that it matters … but I never saw this until “by accident” because I usually never pay attention to “leap-160”
Ya’ll might want to remove the redundant section. (this one)
You should notice that leap-160 is a valid tag the same like leap-155-eol or leap-156…you see the pattern? It is the release…
2 Likes
Thanks @knurpht , @lowtechlinux and @lkocman ! 
Waiting for it to trickle down into Slowroll. 
Would be nice if the points made by @lowtechlinux in the YT video could be addressed, not a big deal for me but I can see it tripping up some users, namely:
- The package not pulling in all the dependencies automatically, it prompts the user to install them instead
- Multiple admin auth requests via polkit (?) for unknown purposes!
OK I’ve tried to have a go, but am failing at the first hurdle …
First problem, port 9000 is already in use on all my machines as it’s the port php-fpm uses and I do not plan on changing that so need to reconfigure cockpit?
Also having installed cockpit-client-launcher via flatpak all I get is a blank window. Running it from the command line I get
Traceback (most recent call last): File "/usr/libexec/cockpit-client", line 18, in <module> import gi ModuleNotFoundError: No module named 'gi'
So something is missing …
:9090 is default I think.
A few troubleshooting ideas:
Is GObject installed?
zypper se -i 'python*-gobject*'
Are you using the native Python provided by openSUSE?
type -p python3
Where is Python looking for libraries?
python3 -c 'import sys; print(sys.path)'
I thought Flatpak was so great. Much better than using your own distro sources. You always get everything brand new. And without errors.
Apparently not so much.
(I had known this for a long time based on various tests.)
1 Like
YEP … found that now, the first post on this thread had :9000 which is what I was following!
/home/linuxbrew/.linuxbrew/bin/python3
OK where the **** did linuxbrew come from and why is it installed in the pigging home directory?
My python3 is now showing Python 3.14.3 while pipx is still working with 3.13.11
On the plus side though, having switched to :9090, I have access to both servers via the browser and that is probably all I need? What does the client add that the browser does not support?
I didn’t say you couldn’t. It’s just a poor replacement and in a lot of the cases not even the best alternative available for users who are just using their desktop. Cockpit is designed for remote access of machines. It is not pretending to be otherwise. It may be easy for some people to use but for a lot of people who are accustomed to using desktop apps and not logging in using port numbers via web address, it is a stupid added level of complexity whether you are using it in a browser or a browser wrapper app.
well, this seems to be an issue with your setup, as no openSUSE product ships python314 as default.
on top of that, I wonder what you installed, as the mentioned cockpit-client-launcher does not exist as a flatpak