The USB controller (Via Labs 805 XHCI) on the RPi4 sits behind a PCIe bus which has no drivers at the moment in u-boot. After implementing it, we'll also have to make sure the USB HID is correctly connected with UEFI routines.

The project aims to port openSUSE to the ROCKPro64. The ROCKPro64 is the most powerful Single Board Computer released by Pine64. It is powered by a Rockchip RK3399 Hexa-Core (dual ARM Cortex A72 and quad ARM Cortex A53) 64-Bit Processor with a MALI T-860 Quad-Core GPU.

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.

I would like to learn Elixir, I plan to do some tutorial and look into books. I if I have time also start with Phoenix the framework for Elixir :smile:

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).

To ease debugging cgroup relates issues this suggests to: - list cgroup hierarchy tree(s),

Whether it's building a newer, upstream UBoot, EDK II, or merely a SLE based rootfs, I want to make this platform a realistic possibility for desktop, digital signage, labs, etc.

Provisioning works with Autoyast/Cobbler for traditional clients, with profiles to enable major version upgrades. The goal is to offer that in a predictable way that can be scheduled and automated for salt minions. Salt minions pose a different challenge, and we would like to enable a reboot into the upgrade without needing PXE not traditional client to enable it.

The idea here is to study and understand how ephemeral storage for containers works and investigate if local storage could be avoided at all and Ceph used instead. Could new storage driver be developed to support Ceph storage: