A set of DSLR remote controller, including:

Some customers are still stuck in a world of 32bit. On ARM64, we have two options for those poor folks:

I want to program a tool to assist building Kgraft-patches.

• As a QA, we mostly thinking filesystem xfs in a researcher mind, some user scenes may not touch. Try to use xfs like a curious user in whole week, and touch features as much as possible, then find the feature which is important but don't cover in our daily work.

The primary arcade machine emulator is MAME, and it has a very specific format for romset compression. I have previously started a project call pyros that allows the creation and update of MAME romsets. The project consists of the following tools:

The day has come to finally merge more and more apps into one single place, and this time it shall be externaltools.

Thinking about extending the typical Twitter app that let's a user bulk-delete their tweets (with a limit of 3200 each time).

openSUSE lacks useable cross-compilers to glibc systems. This is the attempt to provide those, most important a cross-compiler for arm/aarch64.

Project Description

Setup a Home Assistant on Raspberry Pi4 and collect statistics from solar panel energy production

I already have the backend done for the thinkpad umts-card, but the frontend is still missing. The tool shall be a version-2 of https://github.com/asdil12/wwan

In SUSE Manager we want to offer support for bootstrapping systems that don't have the salt-minion installed and configured yet. This can be done using salt-ssh given just a hostname, username and password. See the docs about salt rosters for even more options. What we are missing:

The idea is to use a 8-switch relay (or two) to connect to a Raspberry pi and control the switches according to the music. To control the music, hack mpg123 to take a "frames" file which would contain which channel should be switched on or off.

We used trinity to make fuzzing test, but it hard to reproduce bugs. I'd like to try to use syzkaller or other fuzzy tools to find a stable process to reproduce fuzzy bugs.

Customers are using complex storage stacks such as LVM over dm-crypt over MD RAID over multipath over iSCSI and FC with LOTs of LUNs, and we're facing problems in that area which are usually very hard to reproduce. It's also hard to guard against regressions.

PVH domains are a new guest type supported by Xen being as lightweight as possible (e.g. no emulation of legacy devices via qemu) while taking advantage of the hardware virtualization features of the x86 processor.

I'm planning to get basics of Reactive Programming and especially the documentation in ReactiveX and try some examples from RxPy

The salt-toaster (https://github.com/openSUSE/salt-toaster) is a tool created and developed by SUSE employees that we've been using for testing Salt since few years ago.

My music manager, Bard, was improved in the last hackweek with a very simple React-based web interface but I didn't like the result at all (basically, after learning React I noticed I didn't like it and all the dependencies and the complexity it added) so since then, I've reimplemented the web interface using just jQuery. Also, in the last months I've added musicbrainz data structures to the database (which was also ported to use Postgresql) to prepare bard to use MusicBrainz's data. I also stopped using other python libraries to read audio files and use the ffmpeg libraries directly instead with a c++ wrapper implemented inside Bard which is much much faster.

Salt is moving towards a plugable architecture using POP and Idem. This project is about experimenting with those new concepts by applying them to a real life case: the virt execution and state modules.

Project Description