Retty is a tool for changing stdin,stdout,stderr of a running process (http://pasky.or.cz/dev/retty/) which may be handy if you want to attach to a process running e.g. from a died ssh session, changing running process to run from under screen(1) etc.. Currently it doesn't work for 64-bit systems and it doesn't handle changing of a controlling tty of a process (which may be possible using setsid() and opening a new tty). The aim of this project it to fix the above deficiencies and package the tool in OBS.

Play with Docker orchestration tools like the ones provided by CoreOS, OpenShift and kubernetes. Provide packages for openSUSE and SLE.

see iqlight.com to understand what an IQ Lamp is.

Create a system to allow a community to add contextual information to "open books". Think wikipedia for books

Predicting the non-functional properties of a Ceph cluster can be quite difficult. There are many inputs in the hardware setup and software configuration that affect the resulting availability, reliability and performance (latency and throughput at nominal levels and during degraded and rebuild times).

provide a summary report of data from a sar data file.

I want to revive my "Cloud in a Box" project and this time focus on how OpenStack's Heat automation framework can help with setting up a complete demo or QA environment consisting of several SUSE products (e.g. a SLEPOS Admin/Branch/Client environment).

Although I've been maintaining CRIU package, I had little time to play with it recently. It's still interesting especially in combination with various containers. So let's spend (or waste) some time.

I'm sitting on old patches that implemented predicated value numbering in GCC by combining the algorithms from http://portal.acm.org/citation.cfm?id=512529.512536

There is quite a popular Android software for connection OBD standard adapters but not for older, brand specific ones. One for pre 2001 VAG cars is this one:

The kdump package can now use SMP and multiple targets with constant memory requirements. The goal of this project is to find the optimum parameters for dumping a very large machine (SAP can give me access to 6TB, SGI is able to test with 64 TB).

The idea is to produce a standalone, independent tool to save and restore windows positions and sizes, analogous to a similar feature in KDE desktop. This would be handy in various lightweight desktop enviroments.

If you want to use the full potential of SSDs as primary (and possibly only) storage on SLE or openSUSE systems, you are supposed to perform several configuration settings to make it fly, including:

We had a quick course of Coccinelle during the last Labs conference. The tool is really great and I would like to explore possibility of checking lock invariants for particular functions. Julia was really prompt and implemented something that should help but I didn't get to it since the conference.

Starting with CUPS 1.6 things have changed considerably. Clients are no longer discovering broadcasted printers anymore. Distributions (e.g. Debian) has backported the original protocol into cups-daemon package but this doesn't seem to work either on my laptop. I would like to look and try to understand what the hack is going on here.

cscope is a great tool index C/C++ sources and allow to navigate through the code. I have learned that the project is mostly dead and what is worse it uses its own database format to store the index. I would like to see some extended functionality in the tool - e.g. search whether a function A is reachable from B, filtering search results per-file, fix functions with function parameter detection (such functions are not recognized properly currently) and some others.

The primary motivation for crash-setup (created by l3team) is to make kernel crashdumps deployment and crash using as easy as possible. This has been the case for quite some time except the tool was quite l3slave centric. With a great help from tcech the tool is close to be fully usable from other machines and !.de network as well.

The CRUSH algorithm determines how to store and retrieve data by computing data storage locations. CRUSH empowers Ceph clients to communicate with OSDs directly rather than through a centralized server or broker. With an algorithmically determined method of storing and retrieving data, Ceph avoids a single point of failure, a performance bottleneck, and a physical limit to its scalability. CRUSH requires a map of your cluster, and uses the CRUSH map to pseudo-randomly store and retrieve data in OSDs with a uniform distribution of data across the cluster.