I am making unofficial YaST3 with Python 3 + Qt6 & GTK4. There are already some modules you can use. But keep in mind, it is still Alpha state and something wrong can happen. Bug reports, feature requests and pull requests are welcome!
The plan is to cover most YaST2 modules and add some new ones. Currently there are a lot of AI generated code, which need additional human review (Python experts wanted!). But we will review and clean up everything before 1.0 release in future.
So far, so good. Thank you for any efforts! Appreciated.
Do you think it is really of future? Wouldn’t it be better and more efficient to support projects (like Myrlyn or Cockpit) actively and widenly supported and maintained?
Doesn’t look like rather “high quality” (of project and code). Sorry to say that.
I think the mission of YaST3 is not to provide a final solution but yet another option for those who really miss the old familiar way of doing things.
Myrlyn is a great project. However it only focus on package management. Also, it is written in C++ which I am not good at. I probably will point YaST3 package management module to Myrlyn.
Cockpit is a server focused project, which means it probably won’t care about graphic card driver, keyboard layout, etc. Additionally, some people are just not a fan of web interfaces.
Yeah, I agree. It is now just a rough prototype. A long journey to go before we can see “quality” of any.
I don’t want to kill your enthusiasm, but… (you saw this coming, right?)
…as one of the original YaST2 team members from back in late 1999, I’ve seen several attempts of a rewrite of YaST2. None of them went anywhere; because every single one of those people vastly underestimated the sheer size of the task.
Hacking up prototypes (especially with heavy AI support) is one thing. But it’s the easiest part of it all; and it’s not at all relevant. GUI mockups of trivial things are easy. What is not easy at all are things like
the software architecture
the basic frameworks for the common parts:
a GUI framework, which includes
a text-based (NCurses) framework
a common UI layer that does not make it a problem of the application programmer writing the YaST module which one is actually used, GUI (Qt) or TUI (NCurses), so there is no insane amount of code duplication
a common layer for system-level operations that can run directly on the machine or in a chroot cage; you need that for the system installation, because you need to keep the RAM disk where your installation runs from and the target machine apart
libraries for common tasks that are needed across all kinds of modules, like
installing / enabling / disabling a systemd service
starting / stopping / restarting the network
checking if needed additional packages are installed, and if not, install them
… (the list is sheer endless)
For all this, the first and most important thing to do to even consider such a project is the most boring part:
Collecting the existing features of the old thing (YaST2)
Deciding which of them are actually still relevant
Defining formal requirements from them
Write a user story / a business case / a use case for each one
Sort them by importance (because it will be several orders of magnitude larger than what the available manpower can do)
Make a plan for the implementation based on that importance
Figure out milestones
Win over interested people to do all the work
Try to keep them in the project
Make informed decisions about the tools you intend to use. Don’t pick a random programming language and random toolkits because they happen to be the ones that you know how to work with.
Document things and decisions (because the same questions will be asked over and over again - by each new person joining the project)
Yes, that’s all the boring and tedious part. Nobody wants to do that. Nobody will want to be the project manager, the product manager, the visionary, the architect. But without any of those functions, the project will go nowhere.
I’ve seen too many of those projects start with great enthusiasm and then fizzle out after some time in a lot of frustration.
And finally, please give the whole thing a working project name and don’t burn the name YaST3 at this stage; this is a matter of respects towards the old YaST2 which served us all for over 27 years.
Naming it YaST3 is a bold promise; it implies that it will have as many features as YaST2, it will be maintained for the long run (27 years is hard to beat!), and you intend to stay with it for a similar time period.
OK, that’s enough for right now. I guess the discussion will continue for quite a while.
And further to the above, it is also worth considering that much of the existing YaST2 functionality may no longer be required or relevant today. Some of the older modules exist because they solved problems that were common many years ago, but those requirements have changed or disappeared over time. For example, areas such as printer and scanner configuration have evolved significantly with the adoption of standards-based driverless printing and scanning support in modern devices.
Likewise SELinux integration and there is the pending change to account-utils rather than shadow-pw-mgmt, and even further the implementation of NoNewPrivs which will/could have a big impact…
I rarely used YaST in the last decade, it had it’s moment, these days, once I setup a machine here changes are minimal and it’s more just updating the system, which packagekitd, fwupd and friends (I use Cockpit [Flatpak]) can look after if required.
I use Combustion a lot and now starting to use Agama for system setup/configuration configuration.
It is indeed a demanding project. However, I think this project requires much less than YaST2. PySide6 and GObject are well maintained and documented Python GUI bindings. I won’t need to make my own GUI bridge (like YaST2 did for Ruby). Also, Python is an easier programming language than C++ and more common than Ruby. So potential contributors are more than before.
And next step is to let people in. I think the key point is to support more distros, like Fedora, Debian, Ubuntu, Arch. This will expand its user base.
About naming, if YaST2’s maintainers don’t like it, I can change it to something else.
Just a thought, espcially as you mentioned at the start of the thread that some users dislike web interfaces…Have you considered building a native GTK, Qt or even TUI frontend on top of cockpit-bridge instead? It seems like that might let you inherit much of Cockpit’s existing backend (authentication, privilege handling, system integration, remote management, etc) while replacing only the web UI with a native interface. That feels like it could be a significantly smaller project than recreating a YaST-style management framework from scratch. Was that approach considered?
Yes, I did look into Cockpit for a while. Since I am going with Qt/GTK, Cockpit’s web interface and bridge cannot be used. And I can use polkit directly for auth which is more straightforward than using cockpit. And I also don’t plan to support remote control, which is a web shell security hell…
Fair enough. I wasn’t suggesting reusing the web UI, only the bridge. I was thinking of cockpit-bridge as a backend abstraction, leaving the Qt/GTK frontend to focus purely on presentation.
Remote management via Cockpit does not rely on accessing the web server directly. My understanding is that when you select a remote node in the dashboard, the primary Cockpit instance establishes a standard outbound SSH connection to the target server, launches cockpit-bridge on the remote side, and communicates with it over the encrypted SSH tunnel.
I will try out your Yast3 efforts. I have no significant python expertise to offer.
If you look at openSUSE reviews by the major linux youtubers, the one thing they all cited positively in their reviews was Yast2 as an excellent means of system control. Far better and more comprehensive, according to them, than alternative approaches used in other distros. Now, openSUSE in it’s infinite wisdom is moving away from it.
@tckosvic it was a dead duck so to speak, there is no reason YaST2 can’t be implemented, the source code is available for interested folks to step up, fix, maintain etc? No one has, so…
So a general question to all, how often did you use YaST, and for what tasks?
If all is running well, you shouldn’t need to use Yast. But if you needed something you could easily find it. Now everything is everywhere.
I remember using, with some frequency, printer, network services, users and groups, sound (but that might have been in desktop controls), sysconfig editor, hardware info, and, of course software management.
So many of those features have moved to the main Desktop environments provided.
Users/Groups and Hardware Info are all available via Cockpit (and even features not available via YaST tooling), the openSUSE Cockpit rpms have some nice features that are not available via the flatpak version I use, but I can live with that as I don’t have to install additional packages on the remote systems to still manage what I need, when I need.
Probably for me, the sysconfig editor was the one I used the most over the years for a few things, but vi (or sed) always seemed to be quicker…
for those who really miss the old familiar way of doing things.
