The idea is about an easy way to allow users to make upgrades (e.g.: changing from one major version like 15.0 to version 15.1) using a GUI and as easy as they can in Ubuntu.
Something like a notification with a button to perform the upgrade with just one-click, instead of having to deal with the terminal, that frights some new users and gives them the sensation of an outdated system.
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!
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
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:
TecnoAlarm is a house alarm system. The input devices are communicating with the main node of the system via an RS 485 bus.
In order to be able to plug in such systems in a house automation system, its communication protocol needs to be reverse engineered.
openSUSE Leap 42.3 goes for a rolling release model with automated openQA tests. That covers only so much though. We need manual testing too. In previous releases a google document spread sheet was used to coordinate and track the efforts.That's probably not the best method anymore.
Come up with ideas and a prototype of how manual testing could be guided, tracked, visualized for a rolling development distribution with volunteers testing.
A lot of custom-built or ethusiast-level keyboards such as the Planck, Zeal60, Let's Split and many more use an open-source firmware called QMK. This firmware allows you to freely define your keyboard layout and add a lot of functionality (i.e. emitting a different keycode on long and short keypress, dual-function keys, leader keys (think of vi's :)). We could use the Hack Week to add functionality, check the source code for security issues and add support for more keyboards.
If you own a qmk-running mechanical keyboard or plan on doing so feel free to join me :)
I will deploy a k8s clusters on three pine64 A+ boards, all boards are installed opensuse tumbleweed, and one as k8s-master
two as k8s-minions. The whole cluster will use TLS and BRAC security mechanism.
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.
As there is no BIOS for a PVH domain booting is a little bit different than for pure hardware virtualized guests. To be able to start such a guest a little shim is needed to gather some information about the environment (especially memory layout) before the standard kernel boot path can be entered. By using a boot loader like grub2 this shim can be avoided as the memory information is already known by grub2 and stored into the so called zeropage according to the multiboot protocol.
Lately the necessary patches to get rudimentary support for the Mediatek chromebook with a mainline kernel got posted.
There are some hacks and I'll work on some good solution to get graphics go, at least.
I have noticed that explaining HA cluster concepts to non technical people is not easy (my parents for example hehe).
In order to improve that I would like to create a more visual project using raspberry pi-s.
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:
* pyrex: Tool to create an executable Bash script that will take unorganized files and put them into an organized MAME romset.
With the teres-1  laptop we have a first arm64 device we could use as end-users. Much work to run mainline kernel + u-boot was done already. But power consumption of the laptop is not optimal (~2 hours of battery life time).
The idea is to support cpufreq for the A64 SoC upstream, which would enable the teres-1, pine64 and pinebook to run more power efficient. up to now it seems nobody is working on the driver .
RISC-V is an open ISA (Instruction Set Architecture) based on RISC architecture. It's originated from UC Berkeley and it's attracting more attention in recent years because of its full open architecture so every developer has opportunities to get involved in application processor design or apply it into different applications, such as IoT, Robotics, ... etc.
Any topic about RISC-V is welcome, here are some topics you might be interested in: