Explore Projects

Headlamp currently fetches Kubernetes API data directly from the frontend, which can lead to performance bottlenecks and unnecessary API load. Introducing a caching layer in the headlamp-server backend will reduce API calls, improve response times, and enable more efficient data handling. This enhancement will also allow for improved pagination—fetching only the data needed for the current view—and enable backend-powered search functionality, reducing the need for the frontend to download large datasets. Expected Outcome: 1. A backend caching layer for Kubernetes API responses, scoped per user context to ensure data isolation and security. 2. A new pagination API that allows the frontend to request only the currently visible page of data. 3. A search API that queries the cached data, enabling fast and efficient search without full data downloads. 4. Documentation and possibly a demo video explaining the architecture and usage of the new caching, pagination, and search features.

<p>This project is aimed at providing linear time implementation for modular decomposition of graphs and digraphs. Modular decomposition is decomposition of graph into modules. A module is a subset of vertices and it is a generalization of connected component in graph. Let us take for example a module X. For any vertex v ∉ X it is either connected or not connected to every vertex of X. Another property of module is that a module can be subset of another module. There are various algorithms which have been published for modular decomposition of graphs. The focus in this project is on linear time complexity algorithms which can be practically implemented. The project further aims to use the modules developed for modular decomposition to implement other functionality like skew partitions. Skew partition is partition of graph into two sets of vertices such that induced graph formed by one set is disconnected and induced graph formed by other set is complement of the first. Modular decomposition is a very important concept in Graph Theory and it has a number of use cases. For instance it has been an important tool for solving optimization and combinatorics problems.</p>

Lucene.NET’s current replication system lacks seamless integration with ASP.NET Core and is not modular enough for use across diverse application types like Windows services or cloud-native tools. This proposal focuses on enhancing the `Lucene.Net.Replicator` by introducing full support for ASP.NET Core Dependency Injection (DI), simplifying configuration to a one-liner, and enabling real-time replication using technologies like WebSockets or gRPC. Additionally, it aims to modularize replication components to support non-web environments and build robust unit tests and real-world examples. Deliverables will include: - DI-based configuration system for easier integration in ASP.NET Core and beyond. - Real-time replication architecture replacing polling. - Support for Windows services, CLI tools, and distributed systems. - Comprehensive testing and documentation. These changes will make Lucene.NET replication more developer-friendly, scalable, and production-ready.

<p><strong>hydrus</strong> is a set of Python-based tools which makes it easy and efficient to make powerful REST-APIs serve data. At the moment, hydrus provides mainly CRUD operations over the data served by the REST-API. Users also would like to associate more functionality(dynamic) with the associated routes of the API other than simple CRUD. The main use case would be for cases where modification of data in the server results in some action that needs to happen. Besides that, hydrus supports a basic two-factor authentication using user-nonce and user credentials. The security feature could be greatly improved if we could have a straight-forward way to create an API gateway to the hydrus instances. Also, the hydrus codebase has to be refactored for better readability / maintainability of the code. The current database schema can also be improved which would make hydrus more efficient. The hydrus codebase also lacks a very extensive test suite which needs to be improved. Also, the projects under HydraEcosystem lack good / extensive documentation, which can be improved.</p>

This project focuses on enhancing observability in kgateway’s agentgateway integration by adding support for OpenTelemetry-based tracing, exposing Prometheus-compatible metrics, and configuring access logging. It builds on a previous LFX project that introduced tracing support for kgateway’s AI extproc server, extending those capabilities to support span propagation from agentgateway. Expected Outcome: 1. Translate the existing tracing and access logging APIs in kgateway to enable configuring tracing for the kgateway’s agentgateway integration 2. Create end-to-end (e2e) tests to validate configuration and trace propagation 3. Raise issues for any gaps or friction points discovered during testing 4. Write documentation for plugin developers and end users 5. Writing user-facing documentation and blogs on Otel tracing with agentgateway and kgateway integration with OpenTelemetry-compatible backends 6. Gain hands-on experience with AI providers, OpenTelemetry, tracing platforms, MCP, a2a, Kubernetes, and kgate 7. Fun!

<p>Knowledge-based question-answering system (KBQA) has demonstrated an ability to generate answers of natural language from information stored in a large-scale knowledge base. It has attracted a lot of attentions in the research areas of natural language processing and information retrieval. Generally, it complete the analysis challenge via three steps: identifying named entities, detecting predicates and generate SPARQL queries. In these three steps, predicate detection, a core component of this process, identifies the KB relation(s) a question refers to. To build a predicate detection structure, we identify all possible named entity first, then collect all predicates corresponding to the above entities. What follows is to calculate the similarity between problem and candidate predicates using a Multi-granularity neural network model(MGNN). To find the globally optimal entity-predicate assignment, we use a joint model which is based on the result of entity linking and predicate detection process rather than considering the local predictions (i.e. most possible entity or predicate) as the final result.</p>

<p>Rizin currently relies upon manually writing code for adding a new CPU or an IO port. This implementation is unfit as the vast and growing ecology of hardware components such as CPUs and SoCs regularly implement a part of architecture with custom instructions, registers, and address configurations with trivial differences, making it infeasible to maintain all of them inside Rizin.</p> <p>Providing a level of abstraction in handling this entropy in embedded systems, by supporting editable CPU and platform profiles is the goal of this project. This will also make adding and maintaining these ports easier with less interaction with Rizin’s core. This project also aims to add more flexibility in having a way of importing existing hardware data description documents so that reverse engineering on particular chipsets is easier. This will also help us to memory map the peripheral accesses and registers to provide a better reverse engineering experience. This, in turn, could also be extended to benefit Rizin in terms of compatibility and the end users in terms of user experience.</p>

<p>The Kalman Filter is a method of iteratively predicting the future state of a system based on previous information. Not only is a Kalman Filter more reliable about predicting future state than traditional extrapolation techniques, It also provides a confidence for the estimate. A Kalman Filter is used both to reduce the impact of sensor noise on estimations, and to determine which sensors can be “trusted” more than others. Whereas more primitive methods for estimation and extrapolation rely on some form of averaging, a Kalman Filter forecasts by developing a weighted covariance for each sensor input.</p> <p>The aim of this project is to implement a Kalman Filter in Rust. Rust has gained popularity for providing more compile-time checks than other systems-level languages, namely C and C++. Rust’s memory model ensures that there is little to no room for many of the memory pitfalls common in other low level languages, such as double-freeing memory, dangling pointers, and user-after-free errors. This, in conjunction with high runtime performance, leads writing components of a codebase in Rust to be favorable for both speed and stability.</p>

<p>ChemClipse is program for processing mass spectra and chromatograms. Chromatography and mass spectrometry techniques are widely used tools for life sciences, forensics as well as for quality control issues. ChemClipse is based on the Eclipse Rich Client Platform (RCP). ChemClipse offers tools for PCA (principal component analysis). PCA is statistical method used for reducing the number of variables and to find dependent groups of samples. Chromatograms which are processed by PCA can be easily compared then.</p> <p>Tools which are already included in ChemClipse program offer the following functionality for the data evaluation via PCA: loading of data from ocb files,processing of those data and visualization of results</p> <p>Results can be displayed in a peak intensity table editor, two-dimensional plot or a chart which compares error residues.</p> <p>My main goal is to make this process more user friendly, intuitively and to add new ways to display results. I also want to improve a stability and performance.</p>

<p>Coreboot is a firmware that aims at replacing the initialisation process performed by the BIOS or UEFI firmware at each boot of the computer system that it’s installed on. In order to achieve this, Coreboot has to understand and support the underlying hardware that it is running on, adding a new motherboard can be quite an error-prone and tedious process that can even take up to several months of work if none or just a few of the device’s components are already supported. One of the tools used to make this process easier is SerialICE, a system software debugger that allows the developer to log and intercept the vendor’s BIOS accesses to the hardware and sends the information through a serial or EHCI debug port.</p> <p>This project idea aims at reducing the time and frustration of this process through:</p> <ul> <li>Improving the workflow of adding a new device thanks to a better integration of SerialICE in the developer’s workflow.</li> <li>Allowing access to a recovery and update of the firmware without an OS environment with the use of a flashrom payload.</li> </ul>

<p>Airavata Managed File Transfer (MFT) (<a href="https://github.com/apache/airavata-mft" target="_blank">https://github.com/apache/airavata-mft</a>) is the Apache Airavata’s own Data Movement Implementation Framework to avoid traffic flowing through the Airavata Server when moving the data from one cloud storage to another cloud storage as the moving out the cloud storage to another network seem’s costly with external cloud providers like Azure, AWS, etc due to the increase of the egress traffic.</p> <p>The Goal of the project is to design a user interface using Django for the recently developed new feature MFT ( Managed File Transfer ) of Airavata as per the Mock UX Graphical version developed and available in the Jira EPIC mentioned below.</p> <p>(<a href="https://issues.apache.org/jira/browse/AIRAVATA-3314" target="_blank">https://issues.apache.org/jira/browse/AIRAVATA-3314</a>)</p>

My proposal is to resolve a number of outstanding bugs with WebGL functionality in p5.js, as well as expand on the documentation and tests for that functionality. While the WebGL components of p5.js are increasingly robust, there are a number of open issues that point towards some unexpected behavior and a lack of documentation around certain features. There is also the challenge of structuring the WebGL functions in a way that achieves parity with the p5.js approach to 2d rendering. There are a number of bugs that I would like to resolve, including #5455, #5631, and #5440. For documentation, it seems necessary to make certain additions to better orient developers who are new to 3D graphics and shaders, including graphics quirks that go beyond p5.js, such as the depth sorting challenges mentioned in issue #5420. I would also like to contribute documentation that helps users better understand the structure of WebGL in p5.js, information that is currently only available within the contributor documents. Additional examples would also be helpful for topics like setting up an effects chain or for achieving certain effects such as feedback.

<p>I propose to train a deep neural network to discriminate between various kinds of laughter (giggle, snicker, etc.) A convolutional neural network can be trained to produce continuous-valued vector representations (embeddings) for spectrograms of audio data. A triplet-loss function during training can constrain the network to learn an embedding space where Euclidean distance corresponds to acoustic similarity. In such a space, algorithms like k-Nearest Neighbors can be used for classification. The network weights can be visualized to glean insight about the low- and high-level features it has learned to look for (pitch, timbre, unknowns, etc.) I also propose to obtain visualizations of the embedding space of laughter sounds using dimension reduction techniques like Principal Components Analysis (PCA) and t-distributed Stochastic Neighbor Embedding (t-SNE). I will also apply these same techniques techniques directly on the high-dimension audio spectrograms. All techniques proposed here have been applied previously on related problems in audio and image processing.</p>

<p>The state of art of program repair for heap manipulating program has focus on specific properties of bugs, like null pointer dereference. We try to fix programs with pre-condition and post-condition written in separation logic. Given a program, we first run JSF to collect its post-state(p) by symbolic execution with the given pre-condition. Then we check if p entails the given post-condition(p'). If not, a bug is detected. Our approach to program repair has two main components: abduction and repair specification inference. First, we propose to infer the missing information to establish the post-condition through abduction using an existing solver. In particular, we infer a constraint f such that p * f is satisfied and p * f |-&gt; p'. Secondly, based on abduction, we symbolically execute the input program with the abduction in a backward manner in order to construct repair specifications at every line of the input program. These repair specifications help to infer valid Hoare-style triples with fix candidates.</p>

Ultimate Alarm Clock is a cross-platform Flutter application that needs enhancement with advanced features to provide users with a more comprehensive alarm experience. This project aims to develop 12 key features including negative condition alarms that trigger based on inverse conditions, shared alarm notifications for coordinating wake-up times across multiple devices, timezone-aware alarms, Google Calendar integration, and smart home/IoT integration. Additional features include enhanced snooze customization, sunrise alarms that gradually brighten the screen, task lists for alarms, and advanced alarm insights. The implementation will follow a three-month development plan with regular deliverables, focusing on code quality through UI component standardization and reducing third-party dependencies. The end result will be a significantly enhanced open-source alarm clock application that goes beyond basic functionality to serve modern users' complex scheduling needs while maintaining a clean, intuitive interface across all platforms.

<p>Improve FHIR Search</p> <p>FHIR has a detailed API for searching any kind of medical information. But the API as implemented by the FHIR module provides a very minimal search functionality for most of the resources where you can search by either only one or a few search parameters. There is no search functionality using advanced parameters like _include, _sort, _summary etc. Moreover, there are Lucene indices available for some FHIR resources and the search API for FHIR module doesn’t exploit these indices to provide a quicker search.</p> <p>This project is aimed at improving the search API and implementing/providing support for more complex search operations. It takes into account implementing the search parameters which have already not been implemented for each of the core resources. It would make use of the Lucene index for resources where it is available. Currently, all the search results are returned by the server corresponding to the set of search parameters specified by the user. But this is not always desirable and it is more efficient to return only the top most useful results at a go and hence, this forms an important part of this project by implementing paging for the resources.</p>

CERN uses a service called Service for Web Analysis (SWAN) to perform analyses on scientific data, which is built on top of Jupyter notebook. Currently, the way a notebook kernel connects to a Spark cluster is through SWAN’s own open-source SparkConnector extension. Due to a current Spark limitation, it is not possible for multiple notebooks to share the same set of Spark resources. In addition, the process of spawning the Spark resources could take a while, and may add an inconvenience. Currently, an effort is underway to employ a client-server architecture known as Spark Connect. This would allow multiple notebooks to connect to a previously instantiated Spark session and submit computations to it. To make allocating Spark resources easier for users, this project proposes the development of a JupyterLab extension. The extension shall have a friendly interface that would allow users to instantiate one or more Spark sessions–in which the notebook will be able to connect, configure proper credentials and authentication, and make the connection accessible to the notebook code. The connection and session will be persistent across multiple kernels and restarts.

The Julia REPL and notebooks like Jupyter Notebooks, Pluto.jl both have shortcomings, especially when considering Julia's data science work. For example, the Julia REPL requires additional packages to display images in the REPL and is inconvenient for repeated use. Images also clog the REPL, making it more inconvenient when pre-processing data. On the other hand, notebooks lack debugging tools and waste a lot of space in their layouts. A straightforward and extensible solution that uses the REPL and customizes it to our needs can bridge this feature and convenience gap. The TermLayouts.jl project aims to add extensions to the REPL and introduce a layout in which these extensions can be moved and resized to fit the user's needs. This layout can further be customized using a configuration file. This project will also seek to provide some essential extensions which most users would like to have. These extensions include a variable inspector, a fully-fledged debugger, and a plot area for displaying images. All the code will be thoroughly tested using unit tests and documented extensively for future ease of maintenance.

The Carbon Accounting and Certification Working Group is developing an Operating System for Climate Action, where there is a Hyperledger Fabric Utility Emissions Channel with utility data. Currently, the security certificates for accessing Fabric are held server side. A client application authenticates the user through standard username/password authentication and then access the Fabric chain code on behalf of the user. We would like to explore a client driven authentication for the Fabric application, similar to how Metamask is used with Ethereum dApps such as the Emissions Tokens Network. In such a use case, the user would sign into a web portal, enter and upload their information, and then sign the transaction with a local security key or a dApp wallet such as Metamask. As part of this project, you will learn about 1) Hyperledger Fabric chain code development 2) REST APIs 3) dApp security and wallets 4) Open source development and project management Expected Outcome Implementation of an application with client side authentication for Hyperledger Fabric utility emissions data channel. Documentation and tutorials showing how this is done.

Virtiofs is a shared file system that lets virtual machines access a directory tree on the host. Unlike existing approaches, it is designed to offer local file system semantics and performance. Currently, virtiofsd integrates the sandboxing code and the server code in a single binary. The goal is to extract that code and create an external tool that creates a sandbox environment and runs virtiofsd in it. This will make it easier to develop sandboxing features and virtiofsd side by side. In addition, that tool should be extended to be able to run virtiofsd in a restricted environment with Landlock. Landlock is a Linux kernel module that allows unprivileged processes to restrict their own access rights. This will enable the tool to apply access restrictions to virtiofsd without requiring privileged access, in a way that is enforced by the kernel, thereby increasing the protection of virtiofsd users. This will allow greater flexibility when integrating virtiofsd into a VMM or running it inside a container, due to how Landlock enforces access restriction rules as composable security layers that are compatible with system access controls.

This project aims to extend AsyncAPI suite of community maintained, production ready templates by developing and maintaining a new Java + Quarkus template for generating asynchronous applications using AsyncAPI’s generator repository. Quarkus, a Kubernetes-native Java stack , is an ideal framework for building modern event-driven microservices. This project aims to simplify the development of asynchronous services in Java by generating code and documentation for developers looking to use EDAs in a cloud-native application. Furthermore, this template will be one of the first templates developed inside the AsyncAPI’s generator repository. Allowing developers to test changes locally in the generator repository, making the development easier and reducing the number of workarounds in the template codes. This project will start the improved way of developing and maintaining templates for the AsyncAPI initiative. Key deliverables include: dynamic code generation from AsyncAPI specs using the React engine with integrated WebSocket support, extensions support for Kafka protocol, and a Kubernetes CRD integration.

Enhance Open Cluster Management (OCM) to efficiently schedule AI workloads across multiple Kubernetes clusters by optimizing the use of GPU/TPU resources. Key components: 1. GPU/TPU Resource Evaluation Addon: Extend OCM's placement strategy to include GPU/TPU resource availability. This project introduce an AddonPlacementScore that assesses GPU/TPU resources in cluster sets, which informs scheduling decisions to ensure AI workloads are distributed based on specific GPU/TPU resource requirements. 2. OCM Kueue Admission Check Controller: Deliver a proposal for the external Kueue Admission Check controller integrating OCM Placement results with MultiKueue. The controller reads OCM Placement decisions and generates corresponding MultiKueueConfig and MultiKueueCluster resources, streamlining the setup of the MultiKueue environment and enabling users to select clusters based on custom criteria. Deliverables: GPU/TPU Resource Evaluation Addon, OCM Kueue Admission Check Controller, Comprehensive Documentation and User Guides.

This project proposes the Scheduled ZIM Generation feature for the Kiwix WP1 Selections interface. It introduces an automated system that allows users to schedule periodic regeneration of ZIM files from their selections (like SPARQL or WikiProject-based). Currently, users must manually trigger ZIM generation, which leads to outdated content for dynamic sources. The new system enables users to set a frequency (monthly or quarterly) and a maximum number of regenerations (with a max. like 4), along with email notifications. A scheduling mechanism will run in the backend, checking for due tasks, queuing ZIM generation jobs in zimfarm, sending notifications, and cleaning up old files to manage storage. Key components (deliverables): - A Vue.js UI for configuring schedules, viewing status, and managing tasks. Flask-based REST API endpoints for handling schedule data and triggering generation. - A scheduler to automate task execution. - Email notifications and cleanup logic for outdated ZIMs. - Full test coverage and documentation for both users and developers.