Customers may face problems with their systems we weren't aware of, if we focus on testing single components. We simply can't copy each and every customer setup, but we want to have test results that are more relevant.

Read in a crash or oops-style backtrace and access DWARF information to output the current content of the stack and registers in term of symbols, and the the crash commands to dump/pretty print them. In other words, when looking at a crash dump, answer the questions "Which variable is currently stored in $rax? What is the structure of the stack? Which variable is stored at $rsp+16?"

Status at the end of hackweek 10

<p>Rescue system has a lot of options , but most of them can only be set at boot time, first idea is too provide a way to configure them while the system is running.<p>

some ideas

Building on top of <a href="http://rdimitrov.twistedsanity.net/blog/show.php?entry=Microcontroller%20Class%20D%20Amplifier,%20Rev2&quot;&gt;Rouslan Dimitrov's Microcontroller Class D Amplifier</a>, I developed the idea to feed the power amplifier with PCM data directly. Rouslan does some dithering and noise shaping, but I'm convinced that proper interpolation would sound better. The ATtiny is too slow to do even cubic interpolation so I'll move that into the host.

Talking to people, getting the information about what had happened in the SUSE history, bringing all together to kind of a chronicle. Let's give it a try :-)

SUSE currently consumes a lot of electricity for keeping servers up an running as well as workstations at the office rooms, air-conditions and so on. The project is about to collect information where all the power is going to and to find sweet spots for saving power (and money).

SUSE is using OBS as a build system and openQA for automated testing purposes. The goal of the study is to find out the strengths and weaknesses of these systems and compare them to other open source alternatives in a structured way.