On November 16th there was the release of openSUSE Leap 42.2. On November 24th, I had the opportunity to present openSUSE Project at school.
I was asked to make an introduction to FLOSS in general and more specific about openSUSE Project. The school was for middle aged people, for persons who quited school to work and conftibute financially to their families. There were 3 classes that they taught something computer related. It was a great opportunity for them to learn what FLOSS is and what makes openSUSE great Linux distro. (more…)
As promised in previous posts, we want to share with you our experience and views from this year annual Ruby conference Euruko. Maybe “our” is too much to say, since we only sent one developer there. So to be precise, these are Josef Reidinger’s experience and views on the conference.
This year Euruko took place in Sofia, capital of Bulgaria. It turned out to be a great conference place. Public transport works very well, everyone speak English and even when it uses Cyrilic alphabet, almost everything is written also in Latin one.
That being said, let’s talk about the conference content. Fortunately all the presentations were recorded so you can watch them yourself. But since it would be quite some hours of video to go through, we have reviewed some presentations for you including access to the corresponding videos.
Highlights
Let’s start with the three presentation Josef specially recommend to watch.
Keynote by Matz
He speaks about how Ruby 3 will probably look in distant future. With “distant future” meaning “for sure not in next two years”. If you cannot wait, it’s worth mentioning that Ruby 2.4 will be released on December.
Ruby 3 will use guild membership concurrency model. The most interesting part of the talk is digging into rationale of typed versus non-typed languages and what can be the Ruby future in that regard.
Rules, Laws and Gently Guidelines by Andrew Radev
Interesting view about common design principles, common mistakes when applying them and looking to them from different angles. Also explaining how to handle situations in which several design principles seem to contradict each other.
Elixir by Jose Valim
Interesting intro to Elixir language. What it is, why it make sense to use it and what are its benefits. Josef’s impression was that Elixir’s idea is similar to isolated micro-services communicating via messages, with nice introspection and scalability.
But we have more team members with something to say about Elixir. Like Imobach, who has been playing with Elixir (and Phoenix) for some time now. And Imobach really likes Elixir, so he would like to add some more bits of information for those who are interested.
For example, he would like to highlight that Elixir uses BEAM, the Erlang virtual machine, so great support for concurrency is backed in the platform. Concurrency sits on the concept of Erlang processes and it’s pretty common to use them for all kind of tasks (from computation to storing state, etc.). Imobach would like to encourage all developers out there to take a look to OTP (Open Telecom Platform). Who needs micro-services at all?
Last but not least, take into account that Elixir is a functional language, so if you have an object-oriented mindset (like most Ruby developers) it will take some time to wrap your head around it.
Other presentations
Little Snippets by Xavier Noria
Summary of common inefficiency in small snippets. Small things that matter, although most of them should be already known by the average Ruby developer. (Video)
Since we mention the topic, some YaST team members has found this cheat sheet by Juanito Fatas about Ruby optimization to be quite useful.
Rails + Kafka by Terence Lee
Apache Kafka is yet another messaging system. This talk did not manage to convince Josef to use it, but maybe it makes sense in some scenarios like HPC or HA. (Video)
Graphql on Rails by Marc-Andre Giroux
The typical REST setup is sometimes not scalable enough due to the excess of endpoints. The Graphql language is designed to specify what resources are needed from a server in a single query. The result is returned as JSON and the request specification looks also similar to JSON. Caching is done on client side. Interesting for web stuff and already used by Facebook, Shopify and others. (Video)
Evolution of engineering on call team by Grace Chang
How to maintain services, how to scale when the grow, preventing burnout and so on. Specially interesting for us since there are many similarities with YaST maintenance. Maybe the end of the talk is a bit theoretic and idealistic. (Video)
Sprockets by Rafael Franca
Not specially interesting intro to assets generation used by Rails. People doing some assets generation with Rails would most likely already know all the content. (Video)
Contribute to Ruby core by Hiroshi Shibata
Presentation about Ruby core development infrastructure, rules, etc. Certainly not the best talk ever. (Video)
Consequences of insightful algorithms by Carina C. Zona
Interesting presentation about conflicts between algorithms and real humans, especially with data-mining. Unfortunately, the second half turned to be too emotional and not technical enough for Josef’s taste :). (Video)
Viewing Ruby Blossom – Hamani by Anton Davydov
Introduction to yet another Ruby web framework. Not that interesting for us. (Video)
A Year of Ruby, Together by Andre Arko
Introduction on how the open source community infrastructure behind Rubygems and Bundler is ran. How they get money to improve stuff, how they maintain their servers… Good talk about hard times keeping open source infrastructure alive. Interesting talk for any open source project. (Video)
What I Have Learned from Organizing Remote Internship for Ruby Developers by Ivan Nemytchenko
Talk describing an attempt to scale internship for a lot of students. Josef had a small chat with the author about Google Summer of Code after the presentation. He looked interested. (Video)
The Illusion of Stable APIs by Nick Sutterer
Not Josef’s cup of tea. The presenter probably went a little bit too far trying to be funny all the time. The core of the presentation was about three examples of API that needed to be changed “just” because the rest of the world changed. So the whole presentation can be shortened to one sentence – your API will only remain static if the world remains static. (Video)
Conclusion
That was all from Sofia. See you again in approximately one week, just in time for the report of our 28th Scrum sprint.
Another three weeks of development come to an end… and our usual report starts. Take a look to what we have been cooking.
Read-only proposal modules
This week, during SUSECon 2016, SUSE announced an exciting upcoming new product. SUSE CASP – a Kubernetes based Container As a Service Platform.
That has, of course, some implications for the installer, like the need of some products (like CASP) to specify a fixed configuration for some subsystems. For example, an established selection of packages. The user should not be allowed to change those fixed configurations during installation.
We have implemented a possibility to mark some modules in the installation proposal as read-only. These read-only modules then cannot be started from the installer and therefore their configuration is kept at the default initial state.
In this sprint we have implemented a basic support in the proposal framework, in the future we could improve the respective proposal modules to better handle the read-only mode.
Per product Btrfs subvolumes handling
The ability to have read-only proposals is not the only improvement we have introduced in YaST to make SUSE CASP possible.
When Btrfs is used during the installation, YaST2 proposes a list of subvolumes to create. Unfortunatelly, that list is hard-coded and it’s the same for every (open)SUSE product… until now.
Starting on yast2-storage 3.1.103.1, a list of subvolumes can be defined in the product’s control file along with additional options (check out SLES and openSUSE examples to learn more).
Disabling copy-on-write for a given subvolume (it’s enabled by default).
Enabling the creation of a subvolume only for a set of architectures.
Improved AutoYaST Btrfs subvolumes handling
AutoYaST Btrfs subvolumes handling has been also improved. Using almost the same syntax as for product control files, you can disable the CoW behavior for a given subvolume.
Of course, if you don’t need such a feature, you won’t need to adapt your profiles to the new syntax as it’s backward compatible. You can also mix both of them:
On the other hand, if you’re running SLES, you’ll know that a subvolume called @ is used as the default Btrfs subvolume. Now is possible to turn-off such behavior in the profile’s general section.
We have talked many times in this blog about the new self-update functionality for the installer. As expected, this functionality will debut in SLE-12-SP2 but with a small change in the original plan. In order to ensure maximum consistency in the behavior of SLE-12-SP1 and SP2 installers, the self-update functionality will be disabled by default. Not a big deal, since enabling it to get the latest fixes will be just a matter of adding a boot option in the initial installation screen.
Storage reimplementation: adapted EFI proposal in yast2-bootloader
The previous report about the status of the storage stack reimplementation finished with the following cliffhanger “we have in place all the ingredients to cook an installable ISO“. So, as expected, we worked during this sprint in adapting the bootloader proposal to the new storage layer. As you can see in the following screenshot, we succeeded and the installer can already propose a valid grub2 setup to boot an EFI system.
Does that mean that the testing ISO for the new storage stack is already fully installable? Unfortunately not. Why not, you ask? The reason is, in fact, kind of fun.
The current partitioning proposal only works with MS-DOS style partition tables because we wanted to address the most complicated case first. On the other hand, we intentionally restricted the adaptation of the bootloader proposal to the EFI scenario. And you know what? We found out that combination (MS-DOS partition table + EFI) does not currently work in Tumbleweed, so it neither does in our Tumbleweed-based testing ISO.
We will work during the following sprint to support another scenario. And hopefully we will not choose again an unsupported or broken one. 😉
Letting libYUI run free: first visible steps
As you know, YaST has both a graphical and a textual interface. They run on the same code thanks to an abstraction layer called LibYUI. Originally it served YaST only, but over time other projects started using it, notably the admin panel in Mageia. Moreover, the developers of those projects started to contribute fixes and improvements to LibYUI… faster than we can cope with.
Recently we decided to give the people outside the YaST team more power in the LibYUI project. To make that possible ensuring it does not affect YaST stability, we have been enabling more continuous integration tests.
As a first fruit of the revamped collaboration, we have merged a fix contributed by Angelo Naselli of Mageia regarding selection of tree items. As soon as we complete our continuous integration setup (of course we will keep you informed), more fixes and improvements will come for sure.
More bug squashing and bug paleontology
In the previous report we presented our new effort to integrate the fix of low-priority bugs into the Scrum process. During this sprint we refined the idea a little bit more, distinguishing two separate concepts (each of them with its own PBI) – fixing of existing bugs and closing of too old ones.
The first one doesn’t need much explanation. We managed to fix around 25 non-critical bugs in YaST and if you are using Tumbleweed you are probably already benefiting from the result.
The second task was not exactly about fixing bugs present in the software, but about cleaning bugzilla from bug reports that were simply too old to be relevant any more. Like bugs affecting very old versions of openSUSE that cannot be reproduced in openSUSE 13.2 or Leap. We must be realistic about releases that are already out of support and the limited human resources we have. We closed around 80 of those ancient bugs.
So overall, we cleaned up around one hundred bugs from our queue. Still a long way to have a bug-free YaST, but undoubtedly a step in the right direction.
More coming
We are already working in the next sprint that will hopefully bring several new improvements for CASP, quite relevant progress in the storage reimplementation, several usability improvements, some bugfixes and even some news about this blog.
To make sure you don’t get bored while waiting we are also planning to finally publish the report about our visit to Euruko 2016.
