Technical talks at universities by agamez

Description

This project aims to empower the next generation of tech professionals by offering hands-on workshops on containerization and Kubernetes, with a strong focus on open-source technologies. By providing practical experience with these cutting-edge tools and fostering a deep understanding of open-source principles, we aim to bridge the gap between academia and industry.

For now, the scope is limited to Spanish universities, since we already have the contacts and have started some conversations.

Goals

• Technical Skill Development: equip students with the fundamental knowledge and skills to build, deploy, and manage containerized applications using open-source tools like Kubernetes.
• Open-Source Mindset: foster a passion for open-source software, encouraging students to contribute to open-source projects and collaborate with the global developer community.
• Career Readiness: prepare students for industry-relevant roles by exposing them to real-world use cases, best practices, and open-source in companies.

Resources

• Instructors: experienced open-source professionals with deep knowledge of containerization and Kubernetes.
• SUSE Expertise: leverage SUSE's expertise in open-source technologies to provide insights into industry trends and best practices.

---

SUSE AI Meets the Game Board by moio

Use tabletopgames.ai’s open source TAG and PyTAG frameworks to apply Statistical Forward Planning and Deep Reinforcement Learning to two board games of our own design. On an all-green, all-open source, all-AWS stack!

---

Results: Infrastructure Achievements

We successfully built and automated a containerized stack to support our AI experiments. This included:

• a Fully-Automated, One-Command, GPU-accelerated Kubernetes setup: we created an OpenTofu based script, tofu-tag, to deploy SUSE's RKE2 Kubernetes running on CUDA-enabled nodes in AWS, powered by openSUSE with GPU drivers and gpu-operator
• Containerization of the TAG and PyTAG frameworks: TAG (Tabletop AI Games) and PyTAG were patched for seamless deployment in containerized environments. We automated the container image creation process with GitHub Actions. Our forks (PRs upstream upcoming):
  • https://github.com/moio/TabletopGames/tree/hackweek24
  • https://github.com/moio/PyTAG/tree/hackweek24

./deploy.sh and voilà - Kubernetes running PyTAG (k9s, above) with GPU acceleration (nvtop, below)

Results: Game Design Insights

Our project focused on modeling and analyzing two card games of our own design within the TAG framework:

• Game Modeling: We implemented models for Dario's "Bamboo" and Silvio's "Totoro" and "R3" games, enabling AI agents to play thousands of games ...in minutes!
• AI-driven optimization: By analyzing statistical data on moves, strategies, and outcomes, we iteratively tweaked the game mechanics and rules to achieve better balance and player engagement.
• Advanced analytics: Leveraging AI agents with Monte Carlo Tree Search (MCTS) and random action selection, we compared performance metrics to identify optimal strategies and uncover opportunities for game refinement .
  • more about Bamboo on Dario's site
  • more about R3 on Silvio's site (italian, translation coming)
  • more about Totoro on Silvio's site

A family picture of our card games in progress. From the top: Bamboo, Totoro, R3

Results: Learning, Collaboration, and Innovation

Beyond technical accomplishments, the project showcased innovative approaches to coding, learning, and teamwork:

• "Trio programming" with AI assistance: Our "trio programming" approach—two developers and GitHub Copilot—was a standout success, especially in handling slightly-repetitive but not-quite-exactly-copypaste tasks. Java as a language tends to be verbose and we found it to be fitting particularly well.
• AI tools for reporting and documentation: We extensively used AI chatbots to streamline writing and reporting. (Including writing this report! ...but this note was added manually during edit!)
• GPU compute expertise: Overcoming challenges with CUDA drivers and cloud infrastructure deepened our understanding of GPU-accelerated workloads in the open-source ecosystem.
• Game design as a learning platform: By blending AI techniques with creative game design, we learned not only about AI strategies but also about making games fun, engaging, and balanced.

Last but not least we had a lot of fun! ...and this was definitely not a chatbot generated line!

The Context: AI + Board Games

---

Improve Development Environment on Uyuni by mbussolotto

Description

Currently create a dev environment on Uyuni might be complicated. The steps are:

• add the correct repo
• download packages
• configure your IDE (checkstyle, format rules, sonarlint....)
• setup debug environment
• ...

The current doc can be improved: some information are hard to be find out, some others are completely missing.

Dev Container might solve this situation.

Goals

Uyuni development in no time:

• using VSCode:
  • setting.json should contains all settings (for all languages in Uyuni, with all checkstyle rules etc...)
  • dev container should contains all dependencies
  • setup debug environment
• implement a GitHub Workspace solution
• re-write documentation

Lots of pieces are already implemented: we need to connect them in a consistent solution.

Resources

• https://github.com/uyuni-project/uyuni/wiki

---

Port the classic browser game HackTheNet to PHP 8 by dgedon

Description

The classic browser game HackTheNet from 2004 still runs on PHP 4/5 and MySQL 5 and needs a port to PHP 8 and e.g. MariaDB.

Goals

• Port the game to PHP 8 and MariaDB 11
• Create a container where the game server can simply be started/stopped

Resources

• https://github.com/nodeg/hackthenet

---

ADS-B receiver with MicroOS by epaolantonio

I would like to put one of my spare Raspberry Pis to good use, and what better way to see what flies above my head at any time?

There are various ready-to-use distros already set-up to provide feeder data to platforms like Flightradar24, ADS-B Exchange, FlightAware etc... The goal here would be to do it using MicroOS as a base and containerized decoding of ADS-B data (via tools like dump1090) and web frontend (tar1090).

Goals

• Create a working receiver using MicroOS as a base, and containers based on Tumbleweed
• Make it easy to install
• Optimize for maximum laziness (i.e. it should take care of itself with minimum intervention)

Resources

• 1x Small Board Computer capable of running MicroOS
• 1x RTL2832U DVB-T dongle
• 1x MicroSD card
• https://github.com/antirez/dump1090
• https://github.com/flightaware/dump1090 (dump1090 fork by FlightAware)
• https://github.com/wiedehopf/tar1090

Project status (2024-11-22)

So I'd say that I'm pretty satisfied with how it turned out. I've packaged readsb (as a replacement for dump1090), tar1090, tar1090-db and mlat-client (not used yet).

Current status:

• Able to set-up a working receiver using combustion+ignition (web app based on Fuel Ignition)
• Able to feed to various feeds using the Beast protocol (Airplanes.live, ADSB.fi, ADSB.lol, ADSBExchange.com, Flyitalyadsb.com, Planespotters.net)
• Able to feed to Flightradar24 (initial-setup available but NOT tested! I've only tested using a key I already had)
• Local web interface (tar1090) to easily visualize the results
• Cockpit pre-configured to ease maintenance

What's missing:

• MLAT (Multilateration) support. I've packaged mlat-client already, but I have to wire it up
• FlightAware support

Give it a go at https://g7.github.io/adsbreceiver/ !

Project links

• https://g7.github.io/adsbreceiver/
• https://github.com/g7/adsbreceiver
• https://build.opensuse.org/project/show/home:epaolantonio:adsbreceiver

---

Migrate from Docker to Podman by tjyrinki_suse

Description

I'd like to continue my former work on containerization of several domains on a single server by changing from Docker containers to Podman containers. That will need an OS upgrade as well as Podman is not available in that old server version.

Goals

• Update OS.
• Migrate from Docker to Podman.
• Keep everything functional, including the existing "meanwhile done" additional Docker container that is actually being used already.
• Keep everything at least as secure as currently. One of the reasons of having the containers is to isolate risks related to services open to public Internet.
• Try to enable the Podman use in production.
• At minimum, learn about all of these topics.
• Optionally, improve Ansible side of things as well...

Resources

A search engine is one's friend. Migrating from Docker to Podman, and from docker-compose to podman-compose.

---

Enlightenment in Leap 16 by simotek

Description

Get the Enlightenment stack + X11 building and running on the Leap 16 codebase.

Goals

• Get enlightenment / terminology compiling for Leap 16
• Test that they are running correctly in a Virtual Machine.

Resources

---

New openSUSE-welcome by lkocman

Project Description

Let's revisit our existing openSUSE welcome app.

My goal was to show Leap 16 in a new coat. Welcome app adds to the first time use experience. We've recently added donation button to our existing welcome.

Some things that I recently wanted to address were EOL and possibly upgrade notification.

I've already done some experiments with mint welcome app, but not sure if it's better than the existing one.

There is also a PR to rework existing app https://github.com/openSUSE/openSUSE-welcome/pull/36 (this should be considered as an option too)

Goal for this Hackweek

New welcome app, possibly with EOL notification for Leap.

1) Welcome application(s) with (rebrand changes) maintained under github.com/openSUSE

2) Application is submitted to openSUSE:Factory && openSUSE:Leap:16.0

3) Updated needles in openQA (probably post hackweek)

Resources

Reddit discussion about the best welcome app out there.

Github repo for the current welcome app.

---

New migration tool for Leap by lkocman

Update

I will call a meeting with other interested people at 11:00 CET https://meet.opensuse.org/migrationtool

Description

SLES 16 plans to have no yast tool in it. Leap 16 might keep some bits, however, we need a new tool for Leap to SLES migration, as this was previously handled by a yast2-migration-sle

Goals

A tool able to migrate Leap 16 to SLES 16, I would like to cover also other scenarios within openSUSE, as in many cases users would have to edit repository files manually.

• Leap -> Leap n+1 (minor and major version updates)
• Leap -> SLES docs
• Leap -> Tumbleweed
• Leap -> Slowroll
• Leap Micro -> Leap Micro n+1 (minor and major version updates)
• Leap Micro -> MicroOS

Hackweek 24 update

Marcela and I were working on the project from Brno coworking as well as finalizing pieces after the hackweek. We've tested several migration scenarios and it works. But it needs further polishing and testing.

Projected was renamed to opensuse-migration-tool and was submitted to devel project https://build.opensuse.org/requests/1227281

Repository

https://github.com/openSUSE/opensuse-migration-tool

Out of scope is any migration to an immutable system. I know Richard already has some tool for that.

Resources

Tracker for yast stack reduction code-o-o/leap/features#173 YaST stack reduction

---

YQPkg - Bringing the Single Package Selection Back to Life by shundhammer

tl;dr

Rip out the high-level YQPackageSelector widget from YaST and make it a standalone Qt program without any YaST dependencies.

See section "Result" at the bottom for the current status after the hack week.

Current Status

See the development status issue at the GitHub repo.

tl;dr: It's usable now with all the key features.

It does real package installation / removal / update with reasonable user feedback.

The Past and the Present

We used to have and still have a powerful software selection with the YaST sw_single module (and the YaST patterns counterpart): You can select software down to the package level, you can easily select one of many available package versions, you can select entire patterns - or just view them and pick individual packages from patterns.

You can search packages based on name, description, "requires" or "provides" level, and many more things.

The Future

YaST is on its way out, to be replaced by the new Agama installer and Cockpit for system administration. Those tools can do many things, but fine-grained package selection is not among them. And there are also no other Open Source tools available for that purpose that even come close to the YaST package selection.

Many aspects of YaST have become obsolete over the years; many subsystems now come with a good default configuration, or they can configure themselves automatically. Just think about sound or X11 configuration; when did you last need to touch them?

For others, the desktops bring their own tools (e.g. printers), or there are FOSS configuration tools (NetworkManager, BlueMan). Most YaST modules are no longer needed, and for many others there is a replacement in tools like Cockpit.

But no longer having a powerful fine-grained package selection like in YaST sw_single will hurt. Big time. At least until there is an adequate replacement, many users will want to keep it.

The Idea

YaST sw_single always revolved around a powerful high-level widget on the abstract UI level. Libyui has low-level widgets like YPushButton, YCheckBox, YInputField, more advanced ones like YTable, YTree; and some few very high-level ones like YPackageSelector and YPatternSelector that do the whole package selection thing alone, working just on the libzypp level and changing the status of packages or patterns there.

For the YaST Qt UI, the YQPackageSelector / YQPatternSelector widgets work purely on the Qt and libzypp level; no other YaST infrastructure involved, in particular no Ruby (or formerly YCP) interpreter, no libyui-level widgets, no bindings between Qt / C++ and Ruby / YaST-core, nothing. So it's not too hard to rip all that part out of YaST and create a standalone program from it.

For the NCurses UI, the NCPackageSelector / NCPatternSelector create a lot of libyui widgets (inheriting YWidget / NCWidget) and use a lot of libyui calls to glue them together; and all that of course still needs a lot of YaST / libyui / libyui-ncurses infrastructure. So NCurses is out of scope here.

Preparatory Work: Initializing the Package Subsystem

To see if this is feasible at all, the existing UI examples needed some fixing to check what is needed on that level. That was the make-or-break decision: Would it be realistically possible to set the needed environment in libzypp up (without being stranded in the middle of that task alone at the end of the hack week)?

Yes, it is: That part is already working:

https://github.com/yast/yast-ycp-ui-bindings/pull/71

---

Create openSUSE images for Arm/RISC-V boards by avicenzi

Project Description

Create openSUSE images (or test generic EFI images) for Arm and/or RISC-V boards that are not yet supported.

Goal for this Hackweek

Create bootable images of Tumbleweed for SBCs that currently have no images available or are untested.

Consider generic EFI images where possible, as some boards can hold a bootloader.

Document in the openSUSE Wiki how to flash and use the image for a given board.

Boards that I have around and there are no images:

• Rock 3B
• Nano PC T3 Plus
• Lichee RV D1
• StartFive VisionFive (has some image needs testing)

Hack Week 22

• NanoPC T4

Hack Week 21

• NanoPi M4B
• Radxa Zero

Resources

• https://en.opensuse.org/Portal:Arm
• https://en.opensuse.org/Portal:RISC-V

---