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.
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.
GFXprim is a minimalistic widget library written in C I've been toying with for the last ten years. At this point there are several useful application written in it such as music player, pdf browser, map viewer etc.
(was: Create a DRM driver for Matrox G200)
Even after 20 years, the Matrox G200 series is still an excellent 2d graphics card. Unfortunately, there's only an fbdev driver and a user-space driver. Both are obsolete, as modern Linux uses the DRM framework for managing graphics cards. There already is a DRM driver for the G200 server series. This driver is under-maintained and doesn't work with desktop chips.
rinit is an init written in Rust. It offers a valid alternative to systemd for PID 1 and service management. It uses the supervision to manage long running programs (deamons), log everything to files (no binary log interface) and provides an easy to use command line interface. rinit is already working and able to spawn services and handle their dependencies.
fq is an open source command tool used for formatting and inspecting binary data. It has a modular architecture that allows for adding support for all sorts of different binary data (e.g. MP4, BZIP2, ELF, etc.)
While working on a legacy booting issue for Harvester HCI, I learned about the format of the legacy MBR (master boot record). I started adding support for it in this PR, but I haven't finished it yet. I am interested in better understanding the ways computers boot up so I can better understand what goes wrong when people try to boot Harvester (or relatedly, openSUSE).