During the last GSoC, Jangouts was ported to work on Angular 2. Among other goodies, like the component-based approach or ditching the $scope thingie, Angular 2 leverages the use of observables thanks to its integration with RxJS.
However, when the project started, our student (who did a great job) had to fight^Wwork with a beta version of Angular 2 and, unfortunatelly, the API changed before the release of the final version.
For some of us, Jangouts has become a tool we use everyday. It works (most of the time) and it helps to reduce the impact of having a distributed team.
In the past, Jangouts developers were busy making it to work. But, unfortunately, they didn't pay attention to UX. So the idea of this project is to invest some time trying to improve usability and make Jangouts looks better.
As you may already know, AutoYaST offers integration with Salt and Puppet through the YaST2 Configuration Management module.
Some months ago we got a feature request to add support to Ansible, another quite popular automation tool. It should be rather easy to add basic support for it.
about 6 years
Has no hacker:
A good way of getting to know a new programming language is... writing some code. So although there are some good IRC bouncers, like ZNC, we want to write another one just for learning.
But why an IRC bouncer? Because it is not rocket science, but it implies network communication (acting as client and as server at the same time), handling concurrent connections... in a few words: it sounds fun.
We already tried to improve the Jangouts data model in the past and, although we made quite some progress, we did not finish it. I've been playing a bit with React and Redux lately, and I would like now to try a different approach replacing Angular with that combo. Using Vue.js might be another option too.
Of course, we are not going to rewrite Jangouts in just one week, but let's see how far we can go. By the way, the redesign branch contains some interesting stuff from one of the GSoC that we should consider.
Before the openSUSE 2022, we built a prototype of a command line interface for D-Installer just for demonstration purposes. It implements a limited set of functions and, apart from packaging changes, it has not received any relevant update for months.
Having a terminal you can use at installation time, especially while debugging, is pretty handy. With YaST, you can open a terminal anytime (ctrl+alt+shift+x) in the graphical installation. In the case of D-Installer, you need to switch to a TTY (e.g., ctrl+alt+f1) and stop seeing the installation screen. If you are installing remotely (unless you are using VNC in YaST), you must rely on SSH.
At this point, Agama's Git Hub repository works as the project's website. The README presents the project, explains the architecture, and contains a good share of links to other interesting pieces of information (APIs, design documents, etc.). However, it might be hard to make sense of all that information spread through several documents.
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.