Sat, Mar 11th, 2023

SteamDeck | RetroArch and mGBA for Trading Pokémon

I bought the SteamDeck for a number of reasons. One such reason was to turn it into a portable retro gaming station. I know there are a lot of other options out there to do this task but this one was the most economical and already had Linux installed on it. That meant, very little … Continue reading SteamDeck | RetroArch and mGBA for Trading Pokémon

Fri, Mar 10th, 2023

openSUSE Tumbleweed – Review of the week 2023/10

Dear Tumbleweed users and hackers,

This week we have only published 6 snapshots. One was held back as we identified an issue in one package (libfdisk1) which requires manual intervention (on transactional updates) or an error to be ignored. The problem is in the %postun script of the package, so it’s already ‘on disk’, and thus not fixable. But having seen it, we at least wanted to make sure this will only happen once, and not a 2nd time later on when the script is fixed (transactional-update will learn how to deal with this specific package in the following days; so you can safely let it revert the update for now and let the process play out).

The 6 snapshots published were 0302, 0303, 0304, 0306, 0307, and 0308 and they contained these changes:

  • KDE Plasma 5.27.2
  • KDE Gear 22.12.3
  • Linux kernel 6.2.1. A lockdown patch set was enabled, which created much more issues with 3rd party drivers than it was supposed to. Kernel 6.2.2 will have this disabled again for the time being.
  • YaST has seen a generic version bump to 4.6.0 This was only a version bump without code changes (to open the branch for internal SLE 15SP6 submissions)
  • Mozilla Firefox 110.0.1
  • Python 3.10.10
  • SELinux 3.5
  • libqt5: drop support for systems without SSE2 to fix boo#1208188; this unblocked the LegacyX86 port again
  • GTK 4.10.0
  • A bunch of new x86-64-v3 libraries is showing up in the distribution. Reminder: please don’t blindly enable this on all libraries, but assess benefits (some were identified to have negative impacts in the original analysis)

Staging projects are currently busy testing these changes/additions:

  • Rust 1.68
  • Linux kernel 6.2.2
  • Systemd 253.1
  • Podman 4.4.2 (snapshot 0309)
  • GCC 13 as the distro default compiler
Marcos' Blog posted at 02:21

From zero to double free: The process of creating a reproducer for a kernel vulnerability

The main responsibility of the Kernel Livepatching team at SUSE is to create livepatches for critical security bugs. More important than fixing the bug itself is to guarantee that the livepatch will solve the original problem and not create new ones, so testing the fix properly is crucial. To test a livepatch, you need a way to reproduce the original bug, but how to test a livepatch when you don’t have a reproducer?

Wed, Mar 8th, 2023

openQA-Bites posted at 13:41

VM test cluster using JeOS/MinimalVM images

JeOS (Just enough OS) or MinimalVM images are minimal VM images (duh!) that can be used to quickly deploy VMs. Instead of a installation you only need to go through a first boot setup.

BBC The Green Planet: Quality vs Content

Where should I begin. I bought a 4K Blu-Ray player last Autumn. I did not plan to use it for movies: this was the cheapest way of buying a player for all of my various discs. For a couple of months I really only listened to my CD/DVD-Audio/SACD collection on it.

While listening to TIDAL, I realized that there is a new David Attenborough series out there (the soundtrack was recommended to me by TIDAL). I found some short excerpts on the BBC Earth YouTube channel. In the series, David Attenborough explains the life of plants and also plays with plants just like a little kid. The series is available on 4K Blu-Ray discs. Fantastic, I found something to test the 4K capabilities of my Blu-Ray player.

I ordered the discs from the German Amazon, but they were shipped from Great Britain. In theory there was a simplified customs process, so I did not have to do any paperwork or pay any extra. In practice the Hungarian post office billed me a nice sum as handling fee, even if they did not have to do anything.

The box had four discs inside. The first two are 4K Blu-Ray, the other two are regular Blu-Ray. My initial reaction was that I only need the first two, and I can give away the other two to someone with a regular player. I was wrong.

Obviously, I watched the 4K version of the series. Breath-taking pictures. I have never seen this quality of video recordings previously. Streaming services all have a lot lower bit rate. However, something was missing. You could hear Attenborough talking, but the playful old man, who made the series a lot more of a personal experience, was nowhere to be seen. Checking the box I found that the 4K discs have half an hour less content than the regular discs.

So, all the discs stay with me, I will not give them away. Of course, after watching the 4K version, the FullHD version seems to be a cheap imitation, but the content and mood are a lot better.

Some of the missing content is available on YouTube: https://www.youtube.com/playlist?list=PL5A4nPQbUF8AzMgnRRINtVzk1I2ptf6h8

Tue, Mar 7th, 2023

Syslog-ng 101, part 10: Parsing

This is the tenth part of my syslog-ng tutorial. Last time, we learned about syslog-ng filters. Today, we learn about message parsing using syslog-ng.

You can watch the video on YouTube:

and the complete playlist at https://www.youtube.com/playlist?list=PLoBNbOHNb0i5Pags2JY6-6wH2noLaSiTb

Or you can read the rest the tutorial as a blog at: https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-101-part-10-parsing

syslog-ng logo

YaST Team posted at 12:00

Compare Calling D-Bus in Ruby and Rust

For D-Installer we already have a Ruby CLI that was created as a proof of concept. Then as part of of the hackweek we created another one in Rust to learn a bit about Rust and get our hands dirty. Now that we are familiar with both, we want to measure the overhead of calling D-Bus methods in Rust and Ruby, to make sure that if we continue with Rust, we won’t be surprised by its speed. speed (hint: we do not expect it, but expectations and facts may be different).

Small CLI Scenario

Since we want to measure mainly overhead, we use a simple program that reads a property from the d-bus and print it to stdout. The data structure of the property is not trivial, so the efficiency of so the efficiency of the data marshalling is also tested. We use the D-Bus interface we have in D-Installer and the property was a list of available base products.

The libraries used for communication with D-Bus are well known. For D-Bus we use rubygem-dbus and for rust we use zbus. To keep the code simple, we do not use advanced stuff from the libraries like creating objects/proxies, but simple direct calls.

Ruby Code

require "dbus"

sysbus = DBus.system_bus
service   = sysbus["org.opensuse.DInstaller.Software"]
object    = service["/org/opensuse/DInstaller/Software1"]
interface = object["org.opensuse.DInstaller.Software1"]
products  = interface["AvailableBaseProducts"]
puts "output: #{products.inspect}"

Rust Code

use zbus::blocking::{Connection, Proxy};

fn main() {
    let connection = Connection::system().unwrap();
    let proxy = Proxy::new(&connection,
         "org.opensuse.DInstaller.Software",
          "/org/opensuse/DInstaller/Software1",
        "org.opensuse.DInstaller.Software1").unwrap();
    let res: Vec<(String,String)> = proxy.get_property("AvailableBaseProducts").unwrap();
    println!("output: {:?}", res);
    return;
}

Results

To get some reasonable numbers, we run it a hundred times and measure it with the time utility.

So here is the result for ruby 3.1:

time for i in {1..100}; do ruby dbus_measure.rb &> /dev/null; done

real	0m40.491s
user	0m18.599s
sys	0m3.823s

Here is the result for ruby 3.2:

time for i in {1..100}; do ruby dbus_measure.rb &> /dev/null; done

real	0m31.025s
user	0m16.412s
sys	0m3.441s

And to compare rust one built with --release:

time for i in {1..100}; do ./dbus_measure &> /dev/null; done

real	0m10.286s
user	0m0.254s
sys	0m0.188s

As you can see, the rust looks much faster. It is also nice to see that in Ruby3.2 the cold start has been has been nicely improved. We also discussed this with the ruby-dbus maintainer and he mentioned that ruby dbus calls introspection on object and there is a way to avoid this

Overall impression is that if you want a small CLI utility that needs to call d-bus, then rust is much better for it.

Multiple Calls Scenario

Our CLI in some cases is really just a single dbus call like when you set some DInstaller option, but there are other cases like a long running probe that needs progress reporting, and in that case there will be many more dbus calls. So we want to simulate the case where we need to call progress multiple times during a single run.

Ruby Code

require "dbus"

sysbus = DBus.system_bus
service   = sysbus["org.opensuse.DInstaller.Software"]
object    = service["/org/opensuse/DInstaller/Software1"]
interface = object["org.opensuse.DInstaller.Software1"]

100.times do
  products  = interface["AvailableBaseProducts"]
end

Rust Code

use zbus::blocking::{Connection, Proxy};

fn main() {
    let connection = Connection::system().unwrap();
    let proxy = Proxy::new(&connection,
         "org.opensuse.DInstaller.Software",
          "/org/opensuse/DInstaller/Software1",
        "org.opensuse.DInstaller.Software1").unwrap();
    for _ in 1..100 {
        let _: Vec<(String,String)> = proxy.get_property("AvailableBaseProducts").unwrap();
    }
    return;
}

Results

We see no difference for different Ruby versions, so we just show the times:

time ruby dbus_measure.rb

real	0m10.529s
user	0m0.372s
sys	0m0.039s


time ./dbus_measure

real	0m0.052s
user	0m0.005s
sys	0m0.003s

Here it gets even more interesting and reason reveals busctl --system monitor org.opensuse.DInstaller.Software. Rust caches the property in its proxy and just does a single dbus call GetAll to init all its properties. On the other hand, the ruby library calls introspection first and then calls Get with the property specified. Same behaviour can be achieved in ruby too, but it is more work. So even for simple CLI that needs multiple calls to D-Bus, rust looks fast enough. Only remaining question we need to answer is whether rust proxy correctly detects when a property is changed (in other words, when it sends observer signals by default).

For this reason we create a simple rust program with sleep and use d-feet to change property.

use zbus::blocking::{Connection, Proxy};
use std::{thread, time};

fn main() {
    let connection = Connection::system().unwrap();
    let proxy = Proxy::new(&connection,
         "org.opensuse.DInstaller.Software",
          "/org/opensuse/DInstaller/Software1",
        "org.opensuse.DInstaller.Software1").unwrap();
    let second = time::Duration::from_secs(1);
    for _ in 1..100 {
        let res: String = proxy.get_property("SelectedBaseProduct").unwrap();
        println!("output {}", res);
        thread::sleep(second)
    }
    return;
}

And we have successfully verified that everything is working as it should in the rust.

Request Page Redesign - Diff Comments, Request Actions for Role Additions, and More

For some time now we have been working on the request page redesign. This time we have focused on adding comments on changed or removed lines in a diff, supporting add role requests, and enhancing the requests with multiple actions. The request redesign is part of the beta program. We started the redesign of the request workflow in August 2022. Then, in September 2022, we focused on the support of multi-action submit requests. We continued...

Mon, Mar 6th, 2023

Linux Saloon | 04 Mar 2023 | News Flight 11

This was the 11th News Flight night at the Linux Saloon. I think this episode was a pretty good example of my inability to “read the room” when I brought up the JFS file system article. I think I thought this to be a lot more interesting than perhaps it was. File systems are something … Continue reading Linux Saloon | 04 Mar 2023 | News Flight 11

Sat, Mar 4th, 2023

Cross build and packaging

Introduction Let’s start by clarifying what we mean by cross-building and cross-packaging. Cross-compilation is the process of compiling source code on one platform, called the host, in order to generate an executable binary for a different target platform. The emphasis here is on the word “different”. The target platform may have a different CPU architecture, such as when we work on an x86 computer and want to build software for a Raspberry Pi board with an ARM CPU.