joseivanlopez

YaST dumps quite information to its own log file (placed at /var/log/YaST2/y2log). That info is very useful to understand and discover what is happening when an issue appears. All YaST modules write into this log file, and the brand new yast2-storage-ng is not an exception. Some improvements are necessary regarding to the logging of this new module: * Libstorage-ng is the C++ library powering the rewrite of the YaST storage stack. For using libstorage-ng from yast2-storage-ng in a more Ruby-like way, we created a wrapper that provides several features like automatic downcasting. But the current downcasting mechanism used by the wrapper causes libstorage-ng to introduce a lot of noise in the YaST logs. It would be nice to reduce that noise.

Time for technical housekeeping in the shared Gran Canaria office. For the last couple of weeks, the Cubieboard powering our "SUSE office in a box" has been unresponsive. I want to check why. Fix it, update the system, etc.

The theory behind the partitioning proposal of yast2-storage-ng is that all possible distributions of partitions in the disk are evaluated and the best one, according to this criteria, is chosen. But I have found several examples in which is hard believe that the result is actually the optimal distribution of partitions. So I want to invest some time checking if the error is on my side and the code is indeed proposing the best solution and, if that's not the case, improving the decision making of the code.

I switch fairly often from working on my laptop alone to working on my laptop attached to the dock with several monitors, and I have to move my windows around every time I switch. I want a tool to save and load window/desktop location configurations. I've tried a few tools and scripts that either haven't worked or haven't worked to my liking. I propose to create a tool that will work for openSUSE.

The YaST2 Network module manages network configuration including device configuration, DNS, Routing etc.. The current code is not very object oriented and in many cases there is not a good separation between the business logic and the presentation. The API is also not very clear an many people get confused for example between NetworkInterfaces (class that handles with the ifcfg-files and reside in yast-yast2) and LanItems.

Initially, the Agama D-Bus service was written 100% in Ruby. For many things, it relies on YaST, so it makes sense to use the same language. It was great to have something working quickly, but it also had some drawbacks. The main problem is that, as YaST is not thread-safe, we separated the service into different processes (storage, software, localization, etc.). The system became most responsive but at the cost of eating a lot of RAM.

Moving to Rust