There is a couple of libraries available for asynchronous and non-blocking processing of HTTP requests (in Java) that can be used to avoid having threads waiting for responses in request intensive applications, for example: - Apache HttpAsyncClient

Fresh air and motion helps your brain to come up with new and creative ideas. This hackweek project offers exactly this*. You can expect running exercises along the Nuremberg city wall. Running 25 to 50 meters sidewards, jumping, running stairs, etc. will give your brain new energy.

Doc as Code with Asciidoctor, Jekyll, and TravisCI

Goals: (Subject to change)

The SLE15 development model follows the Factory First policy, where all submissions need to go first to openSUSE:Factory and then to SLE15 repos. This way more bugs are fixed, less patches get lost, less backporting is happening etc. Our openSUSE infrastructure is using salt for configuration management. This was working fine, but suddenly we had to split the openSUSE from the SUSE-DMZ services into separate VLANs, thus the salt codebase had to be split as well. The code itself is mostly formulas and quite similar states between the two set of services though. The only real difference was in the pillars, and even there there was a lot of duplication.

The idea is to create a fantastic robotic SUSE pet using cheap materials. It will be moved with you remote control of your TV. After building the prototype the schemes and Arduino code will be delivered for everyone to try building it at home.

While DDR4 memory has become quite popular, decode-dimms doesn't know about it and is not able to display any useful information for DDR4 memory modules. I would like decode-dimms to provide the same detailed information about DDR4 memory modules as it does for all older memory types.

We started the SUSE Musician's Space several Hackweeks ago, out of which we spawned the SUSE band, now known as SUSE LOUD. Since there are a lot of musicians in SUSE, not all rock musicians, we decided to see whether we could get some other music projects off the ground during this Hackweek.

Automate analysis of zypper logs using the elastic stack Goals

A course on Edx -- "Cloud Computing Infrastructure" -- looks very interesting. I want to spend this hackweek to "systematically" learn more about "cloud computing"

Problem

See how other distros do and solve things and what we can probably learn from them (or where we offer better solutions).

Linux process scheduler is the core of the Linux operating system,and it will directly affect the accuracy and stability of the Linux operating system is running. I want to deep in Process Scheduling Performance test method and tools.

Compared with traditional file systems (e.g. EXT4, XFS), log-structured file systems treat its storage as a circular log and write sequentially to the head of the log. I want to learn about this kind of file system via this hack week, to understand how it manages its data and metadata, to understand how it recover back from crash, to understand its advantages and disadvantages.

Current virtualization requirements mainly come from fate, and I haven't got chance to try freely many features of qemu/libvirt. So I will try to play it.

I'm going to port coreboot to the Dell Latitude E6230 laptop and make it work. Dell Latitude E6230 has two SOIC-8 flash chips. The 4M one which contains the top part of the firmware can be read and programmed, while the 8M one is hard to access via ISP. I downloaded a 12MB ROM from a Google drive made by others.

The goal of this project is to extend and consolidate the tools used by the Emergency Update Team. - Port some of our tools to the maintenance API

I switch fairly often from working on my laptop alone to working on my laptop attached to the dock with several monitors, and I have to move my windows around every time I switch. I want a tool to save and load window/desktop location configurations. I've tried a few tools and scripts that either haven't worked or haven't worked to my liking. I propose to create a tool that will work for openSUSE.

Quite a big part of openQA is testing the installation of SUSE products. All of them are installed by YaST. So a big quantity of problems found during openQA testruns are YaST problems. To find out what has gone wrong during installation YaST developers need to download the tarball containing the logs, unpack it and find the y2log among many other log files. That makes it quite complicated to just have a quick view on a problem.