Fetching the latest programs, projects, and workspace data.
Find open source projects actively accepting contributors. Search repositories, filter by program milestones, difficulty tags, or tech stack.
Use our Orbit AI Matcher to find out! Get instant matching scores based on your developer skills, preferred frameworks, and contribution experience.
Convert your selected open-source project into a winning GSoC, LFX, or Outreachy application using Proposal Studio.
Considering the wide deployment of IEEE 802.11 wireless networks and their shared use of the ISM band, there have been significant efforts in research and development of WiFi rate control algorithms. A notable example of such a rate control algorithm is Minstrel HT, the default for Linux-based OpenWRT access points. In Linux, the rate control is handled in the mac80211 kernel subsystem. As such, the development of rate control algorithms is restricted to the kernel space which includes Minstrel HT. This restriction has posed limitations and challenges in the research and development of rate control algorithms. To this end, this project aims to implement Minstrel HT in user space for OpenWRT access points.
<p>In modern urban areas it is very common to experience a lot of Wi-Fi spectrum congestion in the 2.4GHz and 5GHz bands. High density of omnidirectional antennae per unit area directly translates to low SNR and thus bad wireless performance of our nodes. In the case where we only control one wireless node, not much can be done. We can scan the surroundings and choose the channel with a maximal SNR. But with a node database system, we can simultaneously optimize the spectrum allocation (both in terms of bandwidth as well as the center frequency, i.e. channel) across different nodes. SWOON is an algorithm that would maximize channel capacities over multiple nodes in close proximity.</p>
<p>Currently nodewatcher has very limited overview of used IP space without more precise division of existing and used subnets. This could be improved using compact and colorful matrix with IP ranges and links to nodes. I would display data about used ips similar to the <a href="http://census2012.sourceforge.net/images/hilbert_icmp_map_lowquality.jpg" target="_blank">IP Census 2014</a>, better tables and other data representation that would help explain the network structure, it would help in explaining the network and its statistics even to an uninformed observer. I would also update the look and functionality of other graphs and tables representing statistical data from nodewatcher</p>
<p>Updating the JSON schema to the latest version (2020-12)/draft7 and updating the tools which uses JSON schema to generate forms and validate form data to get compatible with the updated JSON schema.</p>
<p>A dynamical and flexible geolocator, which should give a GPS position based on WiFi information for devices which doesn't have GPS hardware but WiFi. This concept considers 2 main components: the web backend and a package for devices like LEDE (Linux Embedded Development Environment) routers. Especially for Gluon which is a popular framework in the Freifunk community it can be a nice feature to enhance the quality of public maps where Freufunk routers will be visible for the public. Even for geobase routing protocols in the field of the Embedded devices.</p>
Original project proposal: https://projects.freifunk.net/#/projects?project=openwrt_ppa_part_2&lang=en Currently, compiling OpenWRT packages for a device router requires dealing with the non-standard build system SDK. It would be very useful if this could be abstracted away by a generic build system. This project proposes integration with OpenSUSE's OpenBuildService, which also provides automation and remote compilation. The plan currently looks like the following: 1. Document the existing approaches on automating the build system. 2. Write a build script that integrates with the obs-build repository. 3. Get security approval, as documented in https://github.com/openSUSE/obs-build/blob/master/HOWTO.add_another_format. 4. Verify the system works by testing on https://openbuildservice.org. I have already contacted zoobab (Benjamin Henrion), the mentor for this project and I have successfully verified that cascading Docker images successfully compile a package.
LuCI is a framework used to build web interfaces for configuration and monitoring on embedded devices such as WiFi routers, etc. In the old CBI based system, pages were rendered on the router and delivered as HTML to the browser, leading to a higher load on the embedded devices. To address this issue, LuCI applications must be migrated to JavaScript-based framework to reduce the load on embedded devices and improve performance. This migration involves rendering pages on the client-side using JavaScript, rather than on the router. To facilitate this migration, LuCI provides a JavaScript API that will be used to build web interfaces that can be rendered in the browser. To make this migration possible, new RPCD services will be developed to provide data to the client side that was formerly used directly on the router. This data will be provided in JSON format via RPCD (Remote Procedure Call Daemon) and UBUS. These new RPCD services will need to provide the same functionality as the old system but in a format that can be used by client-side JavaScript. The migration of LuCI to JavaScript-based framework will offer several benefits to OpenWrt community and other users of OpenWrt-based devices. One of the primary benefits is improved performance and reduced load on embedded devices such as WiFi routers. By rendering pages on the client-side using JavaScript, rather than on the router, this will reduce the workload on the router and improve the UX for those interacting with the LuCI web interface. This will be particularly beneficial for users with lower-specification routers etc. Another benefit of the new system is increased flexibility for developers. The use of a client-side JavaScript framework provides developers with more options for customizing and extending the LuCI web interface. And this also provides a standardized way for developers to interact with the router's services which should make it easier to develop and maintain LuCI-based applications.
<p>Retroshare is a highly sophisticated communication platform which is accessible only on desktops. This project aims to develop a mobile application focusing on chat rooms, which is the main function of this platform, giving users the ability to communicate also beyond the reach of their computer. This application is to be the basis, which will give the possibility of further development of other functionalities offered by Reroshare.</p> <p>The main task will be to design the application in a user-friendly way, so that the use of this platform, whose advanced architecture may cause problems, especially for less technically advanced users, is easier. The new logo, which is also part of this project, should reflect the new direction of this software. As an additional part, the backend of the chat will be improved to meet the high expectations of users.</p>
Vitess is a distributed database system built on MySQL. Flags are widely used in Vitess for configuring components. As part of a major Vitess flag restructure, support for dynamic flag configuration was introduced. However, several Vitess components have not yet fully adopted this feature. This project involves modifying these components to fully integrate dynamic flags and performing additional flag-related refactors where necessary. Expected Outcome: Improved flag support across all Vitess components, ensuring consistent and flexible configuration management.
The goal of this project is to improve the capabilities of the current integration module of SymPy. To do so, as a first step, rationalizing substitutions will be added, in order to find the antiderivative for functions that SymPy cannot handle. Subsequently, new rules for the handling of special functions will be introduced and the pre-existing code will be improved, which sometimes can report incorrect results for some edge cases. Finally, a module for contour integration will be implemented, in order to be able to calculate specific definite integrals without having to find the antiderivative, handling new cases not yet covered.
This project focuses on building the backend functionality necessary for managing clusters in ITS. It will provide API endpoints to support the frontend’s cluster onboarding and management features. Objectives: - Develop backend APIs for ITS cluster management. - Implement validation and security features for onboarding new clusters. - Ensure high performance and scalability for handling multiple clusters. - Optimize API interactions for faster response times. Expected Outcomes: - A fully functional ITS backend with API support. - Secure and efficient cluster onboarding processes. - Scalable architecture for managing large Kubernetes deployments.
Volcano community has provided Volcano descheduler to support descheduling. Currently, load-aware rescheduling is supported. Resource fragmentation is a problem that users are more concerned about. Volcano needs to provide a resource defragmentation strategy based on the existing descheduler, and needs to ensure that the evicted pods can be rescheduled successfully, which requires the cooperation of the rescheduler and the scheduler to solve resource fragmentation and maximize resource utilization. Expected Outcome: 1. Implementing a resource defragmentation strategy based on Volcano descheduler. 2. The Volcano descheduler works in conjunction with the Volcano scheduler to ensure that evicted pods can be re-scheduled successfully.
CRIU currently does not support checkpoint/restore for UDP sockets with the UDP_CORK socket option. In order for CRIU to support the UDP_CORK socket option, we need to read back the data in the UDP socket send queue at the checkpoint, and restore the send queue data along with the UDP_CORK socket option to the new UDP socket at the restore. In order to implement reading back UDP socket send queues, we need to find a way to extend the Linux kernel that is accepted by the kernel community. In this proposal I proposed 6 technical paths that can be used to implement dumping of UDP socket send queue and analyzed their advantages and disadvantages, including an innovative approach to dumping kernel information using eBPF.
Volcano supports unified scheduling of online and offline workloads, provides a wealth of scheduling plugins and algorithms, and can distinguish different tenants through queue distinction. The current scheduling policy is a global configuration, and all jobs in the queue use the same scheduling policy, but in actual scenarios, different tenants may need to use different scheduling policies due to different usage scenarios. Therefore, volcano needs to support setting and using different scheduling policies at the queue level instead of using a globally unified scheduling policy. Expected Outcome: 1. A new field is added to the queue CRD, and users can set scheduling policies at the queue level. 2. Volcano scheduler implements different scheduling policies based on the queue in which the job is located.
Implement rust wrapper around aries-vcx to enable consuming the library in mobile setting using modern FFI approach using uniffi library. Additionally implement aries mediator client to unlock full mobile support. Learning Objectives - Learn about self sovereign identity and Aries protocols - Learn Rust language - Learn basics of Kotlin language, basics of Android development - Learn Github Actions and CI process in general - Learn about FFI (Foreign Function Interface) by using uniffi library Expected Outcome - uniffi_aries_vcx rust crate which generate mobile bindings for aries-vcx library - implement mediator client with aries message pick-up protocol support - simple android demo application which can be run in simulator - CI job to build Kotlin and iOS bindings, CI job to test the wrapper
Even though a lot of new C++ features are supported by the static analyzer automatically by the virtue of clang AST doing all the work under the hood, the C++17 "structured binding" syntax auto [x, y] = ...; requires some extra work on the Static Analyzer side. The analyzer's transfer functions need to be taught about the new AST nodes, BindingDecl and DecompositionDecl, to work correctly in all three interpretations described by the Standard. Incomplete support for structured bindings is a common source of false positives in the uninitialized variable checker on modern C++ code, such as #42387. It is likely that the Clang CFG also needs to be updated. Such changes in the CFG may improve quality of clang warnings outside of the Static Analyzer. The expected result is that the Static Analyzer correctly models structured binding and decomposition declarations. In particular, binding variables no longer appear uninitialized to the Static Analyzer's uninitialized variable checker.
This project focuses on adding fault injection support in kgateway, enabling platform operators and developers to test system resiliency under controlled failure scenarios. Fault injection allows teams to proactively identify weaknesses by introducing network latency, service errors, or resource constraints. This project will involve designing a configuration API for specifying fault injection rules, implementing support in the kgateway plugin framework, integrating with Envoy’s native fault injection capabilities, and creating documentation and examples to demonstrate practical use cases in Kubernetes environments. Expected Outcome: 1. Create a design doc outlining the proposed API for fault injection and present at a community meeting 2. Implement the fault injection plugin in kgateway, leveraging Envoy capabilities 3. Develop e2e tests to validate fault injection scenarios 4. Write developer-facing documentation with example configurations 5. Create blogs and tutorials demonstrating how to use Chaos Engineering in kgateway 6. Demo fault injection features during kgateway community meetings
Multi-backend framework support of GradSLAM in Ivy by implementing missing PyTorch APIs: Brief Implementation Plan: 1.) Developing support of a basic low-level API of GradSLAM (which is independent of other GradSLAM APIs) in Ivy frontend and backend (by implementing missing PyTorch APIs), along with its corresponding ivy tests. E.g., gradslam.geometry 2.) Follow a similar implementation strategy for other independent APIs (gradslam.config) or high-level APIs dependent on gradslam.geometry (Eg: gradslam.datasets, gradslam.structures, gradslam.slam, gradslam.odometry) 3.) Develop test script same as in official gradslam repo for all APIs. 4.) Create a tutorial (a jupyter notebook similar to official gradslam notebooks as here) for running GradSLAM using Ivy. 5.) Lastly, showcase better runtime performance of GradSLAM using JAX as the backend framework. Deliverables: -> Multi-backend framework (PyTorch, NumPy, JAX, Tensorflow) support for GradSLAM
As a Kubernetes (K8s) network plugin (CNI plugin), Antrea provides networking functions for K8s Pods and includes various troubleshooting tools for cluster administrators and application developers to diagnose networking issues. The PacketCapture feature (https://github.com/antrea-io/antrea/blob/main/docs/packetcapture-guide.md) was introduced recently and allows capturing network traffic for specific endpoints using predefined filters similar to those supported by libpcap/tcpdump. Users can initiate a packet capture through a Kubernetes Custom Resource Definition (CRD) or a CLI command. The Antrea control plane then generates and injects the corresponding BPF program, and the captured packets can be exported as a pcap file. Currently, only a limited set of filters is supported. With this project, we aim to introduce additional filters, particularly Layer 4 protocol filters, such as TCP flags for the TCP transport protocol. These new filters will enable Antrea users to target network traffic more precisely. - Expected Outcome: Extend the API definition for the PacketCapture CRD with additional filter fields, and implement the new API functionality by mapping the new fields to the corresponding BPF instructions. The new fields should also be exposed in the corresponding `antctl` CLI commands. The implementation should come with a sufficient amount of tests (both unit tests and e2e tests), ensuring that the new functionality is working as expected.
Dear Sir, I hope you are doing well. My name is Tianyou Liu, and I am writing to submit my GSoC 2026 proposal for Mogan STEM: “Julia Plugin with Virtual Environment Support.” In the proposal, I describe an implementation plan to enable Julia-powered, reproducible computing directly inside Mogan. The key technical components include: Mogan-side Julia plugin to identify and extract Julia code sections and provide an in-editor execution workflow. A persistent local Julia kernel process to execute code on demand and maintain session state across runs. A lightweight IPC layer between Mogan and the kernel (socket-based, request/response), returning structured execution results for rendering. Output and error capture (stdout/stderr, stack traces, and rich results where applicable) to present execution feedback clearly inside Mogan. Project-aware environment activation by automatically locating the nearest Project.toml (and using Manifest.toml when present) and executing code in the corresponding Julia environment. Integration with Julia’s Pkg workflows to support reproducible dependency management (e.g., activate/instantiate and related environment operations). My resume is enclosed in the attachment. More details are discussed in the proposal enclosed in the attachement. Thank you for your time and consideration. I look forward to the possibility of contributing to Mogan STEM this summer. Best regards, Tianyou Liu Email: liuty2025@mail.sustech.edu.cn GitHub: https://github.com/AXeonV
<p>This proposal is based on a combination of 2 project ideas & 3 tasks.</p> <p>1) ScummVM GUI is currently based on char size strings, so it relies on code pages. There are a <em>lot</em> of character sets and ScummVM supports a wide variety of languages. This means due to the multitude of codepages, we're using:</p> <ul> <li>Unnecessary memory and performance</li> <li>Low compatibility between different languages</li> </ul> <p>The main idea of the of this project is to shift GUI to Common::U32 Strings, which will make our GUI:</p> <ul> <li>Unicode friendly, thus reducing the vast codepages just to one big codepage</li> <li>Better compatible</li> </ul> <p>2) With enhancing our GUI, we're also trying to add support for RTL Languages.</p> <p>3) ScummVM Project has Dynamic Plugins system in place, which allows lower-end platforms to be capable of running ScummVM. However, when we detect games - these plugins are loaded one by one and the relevant detection features are called from the individual engines. Since this is very slow, the main idea of this project is to statically link detection features into the executable so</p> <ul> <li>Games are detected without loading of a plugin</li> <li>Game detection is faster</li> <li>Other parts remain as-is, so our low-end platforms will gain performance boosts</li> </ul>
<p>Allpix-Squared is a free and open-source simulation framework for silicon tracker and vertex detectors written in modern C++. Its goal is to facilitate in-depth studies of silicon-based particle and radiation detectors widely used in high-energy physics. During simulation, Allpix-Squared run events that contains a series of modules that operate on input data — usually in the form of a previous module’s output data. These events aim to mirror the behavior of a particle interacting with a specific detector hardware. Some modules are independent of others, so they can be run in parallel; this is the current state of the multithreading used in the framework, but it does not make good use of available CPU cores. The aim of this proposal is thus to run full events in parallel instead, greatly enhancing CPU core utilization. This however requires some internal restructure and presents new problems not shared with the current approach, such as the issue of event execution order. I aim to solve this issue with dependency graphs. When done, the new multithreading approach should allow better execution time, independent on core count and simulation parameters.</p>
<p>GeNN uses the power of GPU parallelism to accelerate simulations. Currently GeNN only supports CUDA limiting its use to NVIDIA GPUs only. The projects focuses on adding OpenCL support to make it useful for any GPU.</p>