retro-gtk is a toolkit for GTK+-based Libretro frontends. It is mainly used by GNOME Games to play retro games via Libretro gaming console emulators. Currenly retro-gtk supports only software rendering. There are two ways hardware rendering can be used in retro-gtk:

Most large workloads such as SAP HANA require special, highly optimized configuration to run in a virtual machine. Virtual resources such as memory and CPU must be carefully configured to ensure optimum performance of the virtual machine workload. Default VM configuration created by tools such as virt-install are not optimized and often result in poor performance of large workloads due to memory access latencies and incorrect/incomplete information available to the VM's task scheduler. Currently, users deploying large workloads must manually optimize virtual CPU and memory resources, which can be error-prone and if not done properly can actually degrade performance. This project aims to create a tool that can produce suggested vCPU and vNUMA configuration based on a VM configuration template and capabilities of the target virtual machine host. E.g. something along the lines of

The Kubic Project currently produces a "CaaSP-like" Tumbleweed OS, focused on Kubernetes clusters However many of the attributes of Kubic (read-only filesystem, transactional updates, containerised services) could be an interesting platform for another use A Chromebook-like Linux Desktop

1% of SUSE Manager's functionality in 0.1% of the lines of code

Let's create a much simpler SUSE Manager — one you could use at home! Users should be able to deploy and operate in minutes with minimal configuration, while still retaining the very core features that make SUSE Manager useful!

The aim of this project is to finish up the work already done in previous editions of Hackweek in regards to zypper-docker. That being: - Separation of the CLI part and the library.

With all those analyzers for C code we get so much information about our C code. Yet our shell code regularly nukes systems.

We need to package avocado, get it into distro and migrate some of our testsuites from ctcs2. Atm avocado is present in openSUSE:Factory and Backports exist at my home project

There seems to be an overall consensus that the ioctl interface used by ethtool is a poor design as it's inflexible, error prone and notoriously hard to extend. It should clearly be replaced by netlink and obsoleted. Unfortunately not much actual work has been done in that direction until this project started. The project started in Hackweek 16 (fall 2017) and has been worked on since, both in Hackweek 17-19 and outside. First two parts of kernel implementation are in mainline since 5.6-rc1, first part of userspace implementation (ethtool utility) has been submitted to upstream at the end of Hackweek 19 (2020-02-16).

A nice project for enhancing the winter time: Download Model

Rust Emacs clone (sort of), see README for details.