Home Home > 2013 > 10 > 10 > Coming soon: openSUSE 13.1 with YaST in Ruby
Sign up | Login

Coming soon: openSUSE 13.1 with YaST in Ruby

October 10th, 2013 by
YaST during installation

YaST during installation

On July 31st the YaST team announced that the final Ruby conversion of YaST YCP code is over and YaST is now at version 3.0. It took about a week for the new YaST to enter Factory, which makes it a part of the upcoming openSUSE 13.1 release. In the following article we’ll answer the questions of why this change took place, what exactly happened, and where YaST is going. We spoke to two SUSE developers who had been involved with the port, Josef Reidinger and David Majda.

Why did you want to port YaST to Ruby?
YaST was developed in YCP — a custom, simple, inflexible language. For a long time, many YaST developers felt that it slowed them down. It didn’t support many useful concepts like OOP or exception handling, code written in it was hard to test, there were some annoying features (like a tendency to be “robust”, which really means hiding errors). However, original YCP developers moved on to other projects and there wasn’t anyone willing to step in and improve the language.

Josef and David hacking on YaST

Josef and David hacking together

It was obvious that the only way out of this situation is to change the implementation to some other widely used language (most people were thinking about scripting languages, like Ruby or Python, which offer great flexibility and shorter code compared to e.g. C++ or Java). Such a change would mean we wouldn’t need to maintain our own custom language. It would also allow us to use many third-party libraries and make contributing to the project much easier for outsiders. People wouldn’t have to learn a whole new language just because of YaST.
Changing the implementation language of such a big codebase as YaST is a huge effort, so it’s no wonder that developers mostly only talked about it — for years. It required someone external to the team (David) to decide that’s talking isn’t enough and we should just do it :-)

You mentioned in the announcement that the port was done automatically. How did that work?
It was obvious that a manual rewrite is a no-go because of the sheer size of the code base. So we started to hack on a transpiler called Y2R, which would take the YCP code and translate it into Ruby. We worked on it for a week during an internal SUSE workshop. During that time we got into a state where we could translate a code that displayed a simple dialog from YCP to Ruby and run it.

YaST in GNOME

YaST in GNOME

This early success prompted us to work on the project more. We were soon able to translate and run a complete YaST module. Then came the SUSE Hackweek 9, where we involved more people and translated many more modules. After that, the project really gained momentum and several people worked on it full-time for about 3 months, until it was finished.

Why did you pick Ruby?
We chose Ruby because most YaST developers know it well (e.g. from work on WebYaST) and SUSE uses it on several other projects such as SUSE Studio or SLMS. Technically it was on par with other languages we considered (mainly Python and JavaScript/CoffeeScript), so the internal knowledge and standardization was the decisive factor.

How were the results?
Good :-) We translated 96 YaST modules in total and currently there is no YCP code used in YaST except few obscure places like examples in the documentation (which need to be manually rewritten to reflect current best practices). YCP is also still used as a serialization format for some data files and for communicating between YaST components, but this does not affect development and we will probably get rid of that too over time.
YaST team from Prague explaining what they are hacking on

I have to say that the final translation went pretty smoothly, mostly because we automated the whole process and did testing builds months in advance. That meant we had opportunity to catch many bugs in the conversion tools and other components early. We even did our custom builds of openSUSE 13. 1 Milestones 2 and 3 with pre-release versions of YaST in Ruby and announced them publically. As a result, openSUSE community had a preview of what would come and participated in testing and tracking down bugs.

YaST in KDE

YaST in KDE

The amount of converted code is quite impressive:

  • 4.204 files
  • 594.680 lines of YCP deleted
  • 724.687 lines of Ruby added

Are there any differences noticeable, like performance?
So far, we did not focus on any optimizations. Even without them, the memory requirements during installation are only very slightly higher (still you can install in graphical mode on 512M of RAM), the performance is very comparable, depending on the test (sometimes faster, sometimes slower). Even taking the worst results, the difference is hardly noticeable to users. And other than the usual adaptations to things like systemd, there have been no big visible changes in YaST.

What are your future plans?
While we don’t plan any further major changes based on the translation for openSUSE 13.1, we believe that this lowers the bar for getting contribution from the openSUSE community and that it in the future helps the YaST development. Hopefully it will speed up further improvements of individual YaST modules. For beyond 13.1, we plan to do further changes of the YaST architecture.

Tell us all about it!
For example, we have just settled on a new testing framework, RSpec. That will make YaST tests much more maintainable and approachable for Ruby developers. We have also decided to use YARD (a popular tool in the Ruby world) for code documentation. In the coming months we intend to gradually make YaST modules to look more like regular Ruby applications. Right now, while the code is in Ruby, there is still some YaST-specific tooling and code involved, and because of this diving into YaST is not that easy as it could (and should!) be. It also makes things harder maintenance-wise.

We are also in the process of improving YaST development documentation and opening up the whole development. For example, we discarded our internal YaST IRC channel and all discussions happen in public. We now also use a public CI server to run YaST tests.
The overall goal is to lower barries to entry for external contributors and put them to the same level as members of the internal SUSE YaST team.

YaST on the console

YaST on the console

Where to start to hack on YaST?
The entry point to YaST documentation for developers is the YaST portal on the openSUSE wiki with the developer info here. We are currently in the process of updating it to match the changes in code (as a part of hackweek). YaST developers can also be found on yast-devel@opensuse.org, where the port was discussed. And there is the #yast channel on freenode.

What are you looking for in new YaST hackers?
Technicall skills, passion for openSUSE and a desire to configure every bit of it ;-)
Even with the port to Ruby, YaST is big. Luckily the individual modules are not and we’d love to see somebody interested in hacking either on an existing one or create new ones. We would be very happy to answer any questions that will inevitably come as we know the code is under-documented – it would of course help us find out what to document first. Some of us have been hacking on YaST for 11 years, it gets hard to see what is wrong with it after that much time!

Thanks for the interview!
Our pleasure.

Both comments and pings are currently closed.

21 Responses to “Coming soon: openSUSE 13.1 with YaST in Ruby”

  1. Eliasse Diaite

    I wish I were a programmer. I should be the first to offer my contribution to the enhancement of that beloved and unique system configuration tool available in the Linux World.

    Thanks to the whole openSUSE Development Team for the work been done, particularly for the maintenance and improvement of YaST, which without any doubt is the backbone of our favorite Linux distribution.

    Have a lot of fun … openSUSE Linux is unbreakable.

  2. I think this was an important move for opensuse. I once tried fixing the TV detection module but quickly grinded to a halt..

    Even though translating is a big step forward, I hope there will also follow some code cleanup / refactoring as to make it easier for new contributors to find their way (as I can imagine you still have kept some strange code constructs in ruby code due to the translation from yast language)

    *thumbs up*

  3. Maksim

    Why did you want to port YaST to Ruby?
    It’s obvious. Make it slower! Less robust. And you can feel for that for you’ve paid for you new i7 CPU.

  4. Been using SUSE since 7.1 and I’ve always felt there’s lots of possibility for YaST; maybe the rewrite will allow some of that to happen. For example, YaST could do a lot of things that Fantastico does, allowing you to get a Joomla or WordPress or Joomla blog up and running on your server in an instant, or a newsserver or an irc server or something. There could be a whole “server” section allowing you to get some stuff up and running at the same time as you install.

    Looks like this was hard work – thanks!

  5. YastUser

    Latest version of Yast loads up extremely sloooowly. I’m guessing the Yast devs must be using pretty fast hardware to not notice the slow start times. Yast just got a big downgrade if you ask me. It should be light on resources and fast to loadup, neither of which is true.

    Thumbs up for continued Yast development, BIG thumbs down for performace.

  6. jreidinger

    @Maksim Feel free to report bug which module start loading slowly, as we get different results, that it loads faster. So we would like to know what is slower and thanks to ruby profiller we can measure which part takes the most time.

    @YastUser Same for you. Feel free to report what exactly you run and in perfect case measure difference.

    @mxttie Thanks, we plan to improve code, but there is a lot of code so we welcome any help and do not hesitate to ask.

    @Elliasse thanks

  7. I just say “Waaw”

  8. As a lover of Ruby, I find this news very exciting. As a current user of Ubuntu (and not a lover of Python), I may have found my last reason for switching to openSUSE.

  9. randomize

    I remembered something. When Python fails on a Fedora system, you’re screwed anyway. YUM uses Python, so if it breaks, you can’t use YUM, even for repairing Python.

    I wonder… What would happen if Ruby got broken on a system. Then, no YaST, so no way to solve it, at least, for a non-experienced user… I mean, Ruby…? I think it’s not a good idea. Why not C++? Consider Qt. (WebYaST is not an answer).

  10. meh

    I am a huge fan of Ruby but this change makes me nervous.

    WebYast is a horrible piece of software, which doesn’t give me much confidence in their Ruby skills.

    Their time would have been better spent on making the modules better with better docs. Most of the Yast modules suck, to be nice about it.

    • Could you be more specific about what you don’t like on YaST modules?

      (We of course aware of many problems, but we’d like to hear what our users think are the most important things.)

  11. pbl

    That’s quite a triumph you have there. I don’t know Ruby, but at least I know of its existence, which is more than I can say for YCP!

    Question: I’m not a programmer (by training), but by translating a big project like this to a modern OOP language, does it allow to shrink the codebase size, or is that irrelevant?

    • The codebase actually grew a bit after the translation because we reformatted the code completely. We also had to emulate some YCP contructs with Ruby methods calls, which were longer, and we needed to add some boilerplate code at the beginning/end of each file.

      In the future the codebase will likely shrink as we’ll be able to lean more on Ruby ecosystem and remove some custom code we have.

  12. Marc Senn

    message to Suse team

    The Bluetooth Keyboard Bug is since Beta 1 against. (Logitech Blutooth Keyboards/Mouse Serie)

    File
    /lib/udev/rules.d/97-hid2hci.rules
    KERNEL==”hiddev*” Standart

    Edit to KERNEL==”hidraw*”

    Please correct OpenSuse 13.1 RTM

    YaST is Cool half second to start (OpenSuse 13.1RC1)

  13. Marc Senn

    Sorry Since OpenSuse 13.1 Beta 1 :-)

  14. Muhammad Azharuddin Qadri

    just one Question Can I dual boot opensus with Windows 7 boot loader with the help of Easy BCD’s, like I am using Ubuntu that is easily boot any part of my HDD and no Effect on my MBR.

  15. Timothy

    As you have successfully translated YaST into a more well know programming language this will make it much easier to get outside contribution. But as YaST is still very old technology and you make it known that it is somewhat problematic still and will be for a very long time please consider creating a project to produce a more modern System tool using QT 5.2.

    As KDE is the default and preferred desktop environment for the vast majority of openSUSE users having a system configuration tool that integrates nicely into the main desktop would be very nice.

    Also it is of course possible to utilize a number of existing libraries from KDE and then simply expand them out. These additions could also be submitted to KDE as well and possibly pull in a large development crowd as it would benefit many distros. With the basic functionality in KDE available it would provide at least a good starting point for a lot of basic functionality.

    Modularizing the code base to be a pluggable module framework for example would still allow for openSUSE Zypper software management as well as other distro drop in replacement for Yum/Debian etc.

    Also was the terminal version of YaST heavily affected by this change as well?

    Even if you are not interested in looking to fully move away from YaST to a built from scratch modern futuristic and tightly integrated QT/KDE based toolset please consider hosting a side project for this as a possible future alternative to YaST.

  16. pbl

    It is true that there could be a little confusion between the “system configuration” in kde and YaST, but I just don’t see how YaST is “problematic”, as you say.

    Doing this integration that you speak about would doom any non-kde opensuse users to install kdelibs, if not kde. There are some people who really don’t like kde. I don’t understand why, but I respect their choice. And what if kde folks start smoking crack just like the gnome3 people did? We would have no choice but to comply, or else keep using deprecated libraries. No, I believe that a desktop agnostic solution remains superior.

    You already a good Qt integration in YaST. For instance, even if you are in gnome, you can use the qt-yast.

    Anyway, you may fork YaST anytime if you wish. No need to ask anyone to start hosting.