This is a task to update current WSL-Launcher (which can be already buildt in OBS) with latest-greatest upstream code https://github.com/Microsoft/WSL-DistroLauncher Fork of fabian's project (initial work to get it working):

This is a task to update current WSL-Launcher (which can be already buildt in OBS) with latest-greatest upstream code https://github.com/Microsoft/WSL-DistroLauncher Fork of fabian's project (initial work to get it working):

During the previous Hackweek [0], I have successfully implemented, tested and merged [1] an implementation of the entire C++ standard header <future>. This time, my aim is to modernize the C++14-esque standard library [2] of HelenOS [3][4] with a C++17 feature - the <filesystem> header. The <filesystem> header is much larger than the <future> header which I barely managed to implement and test in the allocated time for the previous Hackweek, but <future> was mostly OS-independent as it relied only on previously implemented features of the standard library. The <filesystem> header, however, is limited by the filesystem API of the OS and as such implementing of the entirety of it might not be possible, limiting the scope of the project (which is a good thing due to the time constraints). The primary features of the header [5] that should be implemented:

transactional-update, the application to update read-only systems such as openSUSE MicroOS and openSUSE Kubic and the Transactional Server installations of openSUSE Leap, openSUSE Tumbleweed and SUSE Linux Enterprise Server, evolved from a POC to a fully fledged solution - and is currently completely written in Bash. This has been working really well in the past, but is gradually reaching its limits, especially when thinking about supporting additional file systems or ports to other Linux distributions - yes, we have a huge interest in other distributions adopting our technology. A C++ version would simplify those abstractions, but would it also make maintenance of the complete application easier? Check that as part of a POC and refresh C++ knowledge on the way there.

Currently AWS uses a SMT solver to decide on public/non-public policies https://aws.amazon.com/blogs/security/protect-sensitive-data-in-the-cloud-with-automated-reasoning-zelkova/ Learn about SMT solvers & see how feasible using a smt solver is for supporting the more minimal policy set in ceph object storage RGW

Let's pick some old classic game, reverse engineer the data formats and game rules and write an open source engine for it from scratch. Some games from 1990s are simple enough that we could have a playable prototype by the end of the week. Write which games you'd like to hack on in the comments. Don't forget to check e.g. on Open Source Game Clones, Github and SourceForge whether the game is ported already.

Project Description

The kdump plumbing is implemented as a dracut module. The original intention was to reuse the logic that dracut uses to deal with storage and network, but it turns out that kdump needs are often very different, so a lot of time is spent on avoiding dracut features that are undesirable.

Project Description

DNF 5 is a package manager that is currently in development and will land in the future Fedora and RHEL versions.