Project Description
This is a continuation of last year project: trying to move more components from MicroOS Desktop from the hostOS to container.
Goal for this Hackweek
- investigate issues in gdm container ( https://github.com/fcrozat/gdm-container ) when installed on bare system
- test flatpak builds on OBS
- test flatpak shipped as OCI container
- continue my quest to move more "desktop like" workload into containers, such as rclone / restic ( https://github.com/fcrozat/rclone-container )
Looking for hackers with the skills:
This project is part of:
Hack Week 21
Activity
Comments
-
almost 3 years ago by fcrozat | Reply
State of the Art regarding Flatpak and OCI containers:
- Flatpak can be distributed two ways:
- as ostree directly
- as ostree but bundled into OCI containers
- For building flatpak as OCI:
- you need a local build stored as ostree (usually done using flatpak build)
- local ostree is bundled as OCI tarball using "flatpak build-bundle --oci" (option --runtime to create runtime flatpak)
- Fedora has created some tooling around this https://pagure.io/flatpak-module-tools but they are relying on Fedora Modularity
- additional Fedora documentation: https://docs.fedoraproject.org/en-US/flatpak/tutorial/
- caveat of using OCI for flatpak:
- download size when upgrading: https://groups.google.com/a/opencontainers.org/g/dev/c/daBUKI3KkRk/m/Gb2tFXMGAQAJ
- GPG signature not implemented for containers: https://github.com/flatpak/flatpak/blob/4247e61fbe8ffc9f6b095240159f53f73568378c/app/flatpak-builtins-remote-add.c#L348-L351
- cosign not implemented
- currently, distributing flatpak using OCI registry requiring additional http(s) server to provide index of all flatpak available on the repository:
- this is why the uri used for those is oci+http or oci+https
- this customization doesn't make easy to publish flatpak on any random OCI registry
- this customization is badly documented (or at least, difficult to find online):
- some discussions were done at opencontainer level : https://groups.google.com/a/opencontainers.org/g/dev/c/ehjHDL4uPJE?pli=1
- there is a blog post at https://opencontainers.org/posts/blog/2018-11-07-bringing-oci-images-to-the-desktop-with-flatpak/
- the protocol is https://github.com/owtaylor/flagstate/blob/master/docs/protocol.md
- initial implementation at https://github.com/owtaylor/flagstate/
- production implementation for the indexer is https://github.com/owtaylor/flatpak-indexer but is RH infrastructure specific
- End results is visible at https://registry.fedoraproject.org/static/ (corresponding to oci+https://registry.fedoraproject.org/ )
- some people were able to "duplicate" this using github workflow : https://github.com/TheEvilSkeleton/flatpak-remote
- the static page part is at https://github.com/TheEvilSkeleton/flatpak-remote/blob/main/.github/workflows/flatpak.yml#L148=
- As this requires custom development to get this working with our infrastructure, it makes no sense to invest supporting oci+https
- upstream has a issue opened to switch to "pure" OCI registry:
- https://github.com/flatpak/flatpak/issues/4744
- this is a new feature request upstream and it still at discussion phase. We should participate actively (contribute ideas or even code) if we want to switch to Flatpak over OCI
- On OCI front, there is not support for a search api (see https://github.com/distribution/distribution/issues/206 and https://github.com/opencontainers/distribution-spec/issues/71 ) but I might have missed some upstream discussions. We should ask our OCI specialists at SUSE. There was a proposal for a _catalog api but it was dropped https://github.com/opencontainers/distribution-spec/issues/22
- Flatpak can be distributed two ways:
-
Similar Projects
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
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.
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
Enable the containerized Uyuni server to run on different host OS by j_renner
Description
The Uyuni server is provided as a container, but we still require it to run on Leap Micro? This is not how people expect to use containerized applications, so it would be great if we tested other host OSs and enabled them by providing builds of necessary tools for (e.g. mgradm). Interesting candidates should be:
- openSUSE Leap
- Cent OS 7
- Ubuntu
- ???
Goals
Make it really easy for anyone to run the Uyuni containerized server on whatever OS they want (with support for containers of course).
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
Write a shell extension for GNOME by tdz
Description
I usually do kernel and systems programming. This project is about learning more about the userspace and application side. Writing an extension to gnome-shell seems like a good place to start. The GNOME shell is scriptable via JavaScript and a number of such extension is available from upstream.
On X11, there used to be a toy rsp. screensaver called XPenguins. After the desktop being idle for some time, it sent penguins falling down the screen and walking along window borders. It doesn't work any longer with Wayland-based compositing, but re-implementing it as extension for the GNOME shell might be possible. There already existed a port around a decade ago that could serve as starting point.
Goals
- Learn about how shell extensions work and how to write one
- See if XPenguins can be converted
- If successful, try to upstream the result
Resources