YaST is being rewritten in Ruby


Recommended Posts

For those not intimately familiar with SUSE and openSUSE, it bears mentioning what YaST actually is. YaST is our administrative control panel, composed of numerous modules for Software Management, User Management, Partitioning, and a variety of other tasks. It has interfaces implemented with GTK, Qt Project, and a command line interface. The command line interface is particularly nice in the case that you are running a server without a graphical environment, or if for some reason your graphical environment is not working. YaST even powers our very advanced graphical installer, providing us with power and stability during the install process that I haven't seen any other distribution able to replicate. WebYaST brings the power of YaST to remote administration, allowing you to remotely administer your machines from a comfortable web-based graphical interface.

For a couple of years now I've been hearing rumors about YaST being switched to Ruby from the proprietary YCP language. However, up to recently I haven't stumbled across any substantiating evidence. Fact of the matter now though is that it is happening, and the next openSUSE release may even use the new Ruby based YaST.

Firstly though, why bother? It after all does work, and quite well for that matter. There are numerous reasons why this transition is being made. Firstly, YCP is a language developed explicitly for YaST development, and thus the only people who know it are YaST developers. This cuts out many people who would otherwise be able to contribute to it's continued evolution and maintenance. But why Ruby? Other similar (and inferior in my opinion) tools are usually written in Python . Largely this is due to the simple fact that SUSE has many proficient Ruby developers. But, Ruby in it's own right is an excellent choice due to it's simplicity, flexibility, and the rapid development it enables. Also, it bears mentioning that WebYaST is based on Ruby, and so this would enable tighter integration and remedy duplication of effort enabling the two implementations to share more code.

The new Ruby implementation is being worked on by SUSE developers in Prague. It appears they are using a code translation scheme as the starting point similar to what Xamarin used when they rewrote the Android OS to use Mono. The new code has already been used to effectively install and administer an experimental build of openSUSE, and the developers feel confident of having it ready to begin integration by Milestone 4 of our next openSUSE release 13.1.

Personally I think this is an excellent move, as it would allow us to do more rapid development and innovation around YaST. Also, it would make YaST more accessible to other projects that might be interested in using or adapting parts of it for their own purposes. However, it should come as no surprise that if it does make it into openSUSE 13.1 it may introduce some new bugs that could prove a pain during installation or for new users. Nonetheless, I feel that this is certainly the right direction and will point us towards a promising future of innovation with YaST.

Source: http://opensuseadven...ruby-geeko.html

I don't remember seeing any posts in this subforum about openSUSE, but I thought I would post this article because I find it interesting. I do not use openSUSE, and haven't even installed a copy of the distro since 9.1, but I generally follow major developments in package management software for the most influential GNU/Linux distributions. I remember YaST being very pretty and intuitive, but also horribly slow. Although a lot has changed since I last used it, a cursor glance at the official openSUSE forum seems to indicate that speed is still an issue. While switching to Ruby is very unlikely to make it faster (since Ruby has known performance issues of its own), it will be very interesting to see how smoothly their conversion process goes, and to see how easily the YaST development team is able to maintain the generated Ruby code base.

Link to comment
Share on other sites

While switching to Ruby is very unlikely to make it faster (since Ruby has known performance issues of its own), it will be very interesting to see how smoothly...

Yea, a little puzzled by that one too. Ruby has a lot of benefits, but If speed was an issue, Ruby certainly wouldn't have been my first (or the 10th) pick. Decent to work with, I work with a few Ruby based programs and they're quite good (I love Redmine..), but they're fairly slow in both execution and startup.. shoot I've seen a few benchmarks put it behind Python and PHP in some areas, if you put any faith in those. Personally, YaST is one of the things that's irritated me with OpenSUSE over the past few years, overall a pretty nice and polished distro but wrestling with that thing when it gets finicky can be a turnoff. Even if it doesn't help with the performance, any improvements to YaST in general would be a bonus.

Link to comment
Share on other sites

Yea, a little puzzled by that one too. Ruby has a lot of benefits, but If speed was an issue, Ruby certainly wouldn't have been my first (or the 10th) pick.

From what I read elsewhere (I think it was on the main openSUSE development mailing list, but I'm not sure) the team considered several languages as a potential replacement for YCP, including Python and Mono (C#), but ultimately chose Ruby because most of the core YaST developers are very competent in it already. The idea behind the change in language is to make YaST development more stable long-term and to (hopefully) attract more developers by using a mainstream language. I don't think anyone in the openSUSE project is particularly conserned with speed, including the YaST team.

Link to comment
Share on other sites

They probably went with Ruby because it would be easy to expose everything to Puppet or some other system management system.. native interfaces for desired state config could be helpful..

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.