# gsoc Published articles for gsoc. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## QEMU Google Summer of Code 2026 project report DevFeed: [QEMU Google Summer of Code 2026 project report]() Original publisher: [Read original article]() Published: 2026-09-15T07:00:00Z Content type: article Language: en Sources: [QEMU]() Topics: [qemu](), [AdventureX 2025](), [Open Source](), [virtual machines](), [x86](), [observability](), [Rust]() Tags: [cpu](), [development](), [google-summer-of-code](), [gsoc](), [internships](), [observability](), [open-source](), [qemu](), [rust]() ### AI overview QEMU's Google Summer of Code 2026 report covers four contributors' open-source projects from May through August, including lazy snapshot loading, x86 Process Context Identifier support in COCONUT-SVSM, and observability support for confidential virtual machines. ### Source excerpt QEMU participated in Google Summer of Code 2026 with 4 contributors working on open source internships from May through August. The contributors gained experience in open source software development working on 12-week projects. ## GSoC 2026 Final Report | Modernizing Haiku's Bluetooth Stack: HID Profile Implementation DevFeed: [GSoC 2026 Final Report | Modernizing Haiku's Bluetooth Stack: HID Profile Implementation]() Original publisher: [Read original article]() Author: mohammedrattia Published: 2026-09-06T12:00:24Z Content type: article Language: en Sources: [Haiku Project]() Topics: [Bluetooth](), [implementation]() Tags: [bluetooth](), [drivers](), [gsoc](), [gsoc2026](), [haiku](), [hid](), [implementation](), [input](), [report](), [software]() ### AI overview This final GSoC 2026 report describes work to improve Haiku's Bluetooth stack and implement the HID profile. It reports that Bluetooth mice and keyboards are functioning and that the core stack is ready for additional profiles, while noting that Low Energy Bluetooth remains unimplemented and further work is needed. ### Source excerpt Hello! Finally, GSoC is done for me. This is the final report for my project. The project was focused on improving the Bluetooth stack and making it useful. Hopefully, the Bluetooth stack is now in a much better state than before GSoC 2026. It still needs much work to be fully developed. However, currently Bluetooth mice and keyboards are functioning. In addition, the core of the stack is ready for implementing other profiles. This report will include the following: Project Overview What I Did Future Work Conclusion Project Overview The State of Bluetooth on Haiku Before GSoC 2026 Although the Bluetooth stack was outdated (based on version 2.0 and 2.1 of Bluetooth) before GSoC, it contained many core components that helped us focus less on starting from scratch and more on making the already built stack useful. However, that's true only for BR/EDR (Basic Rate / Enhanced Data Rate) Bluetooth, not Low Energy Bluetooth, which isn't implemented yet in Haiku. The BR/EDR Bluetooth core stack is divided into several core modules that provide services for the Bluetooth profiles, which in turn provide services to users like human interface devices, audio, file transfer, etc. Some of those core modules and their state in Haiku are: L2CAP: Functional, but needed some fixes. HCI (Host Controller Interface): Functional, but on an old Bluetooth version, as stated above. Transfer Layer (h2generic): Functional, but required further extension to cover vendor-specific devices. Preferences Application: Functional, but it lacked some features, such as changing the Bluetooth friendly name, canceling inquiry and pairing, and adding devices to a block list. Security Manager: Not complete; it's blended into the Bluetooth Server, and most of its functions were missing. Service Discovery Protocol (SDP): Not implemented. The state mentioned above meant the Bluetooth stack couldn't yet offer much practical functionality to users, because none of the Bluetooth profiles were implemented. In addi ## \[GSoC 2026\] Modernizing Haiku's Bluetooth stack: Implementing support for HFP profile - Progress Report DevFeed: [\[GSoC 2026\] Modernizing Haiku's Bluetooth stack: Implementing support for HFP profile - Progress Report]() Original publisher: [Read original article]() Author: vighnesh-sawant Published: 2026-08-21T18:04:07Z Content type: article Language: en Sources: [Haiku Project]() Topics: [Bluetooth](), [Protocol (disambiguation)](), [implementation](), [bug](), [USB]() Tags: [bluetooth](), [bug-fixes](), [gsoc](), [haiku](), [implementation](), [progress-report](), [software](), [usb]() ### AI overview This GSoC 2026 progress report describes work modernizing Haiku's Bluetooth stack for the Hands-Free Profile (HFP). It covers RFCOMM implementation, xHCI improvements, Bluetooth stack and media fixes, HFP session functionality, and a Bluetooth SCO Media Kit add-on. RFCOMM and SCO are nearly ready for merging, while HFP still needs to be split, reviewed, and prepared for merging. ### Source excerpt Introduction The goal of this post is to document the changes I made during the GSoC period and the current state of the project. I would also like to thank waddlesplash for his continued support throughout the project. Progress So Far RFCOMM Protocol RFCOMM is now almost ready to be merged. It acts as the control channel required by HFP. The implementation includes: RFCOMM socket addressing and connection management DLCI multiplexing over a shared L2CAP connection SABM, UA, DM, DISC, and UIH frame handling MCC commands Credit-based flow control USB and xHCI Improvements During implementation, I found that the xHCI driver assumed all isochronous packets had the same size, which is not always true. The xHCI driver now supports variable-length isochronous packets and processes completed transfers in FIFO order instead of LIFO order. Bug Fixes A part of this period was spent fixing issues in the existing Bluetooth stack. The main fixes include: Correcting ACL packet splitting when packets exceed the L2CAP MTU. Holding socket references while working on them. Related changes include the L2CAP refactor,send-status fix, socket lifetime changes, and MTU packet fix Media Stack Fixes While working on Bluetooth audio integration, I found some bugs in the media stack. After initial work, waddlesplash took over these changes and implemented the actual changes. The improvements landed in the media auto-stop change and the live output reconnection change. Hands-Free Profile The first pass for HFP is done. It includes: Hands-Free service discovery through SDP. HFP session management. Basic AT-command parsing. The implementation is functional but work is needed to split the changes, getting it reviewed and making it merge ready. Bluetooth SCO Media Add-on The Bluetooth SCO Media Kit add-on has also been implemented. It discovers Bluetooth audio devices, exposes them through the Media Kit, and creates media nodes for headset playback and capture. It includes: Bluetooth headset disco ## \[GSoC 2026\] Expanding the functionality of the Haiku Devices Application - Final Report DevFeed: [\[GSoC 2026\] Expanding the functionality of the Haiku Devices Application - Final Report]() Original publisher: [Read original article]() Author: aquamatic123 Published: 2026-08-21T15:52:01Z Content type: article Language: en Sources: [Haiku Project]() Topics: [App](), [Hardware](), [GUI](), [USB](), [configuration](), [User Experience](), [Kernel](), [Testing]() Tags: [2026](), [api](), [application](), [configuration](), [devices](), [gsoc](), [gsoc2026](), [gui](), [haiku](), [hardware](), [kernel](), [report](), [software](), [unit-tests](), [user-experience]() ### AI overview This final report describes a Google Summer of Code 2026 project that expanded Haiku's Devices application from a basic hardware list into a more capable management utility. The work added driver mapping, USB and HID descriptor inspection, packaged-driver blocking with safety checks, unit tests, alphabetical sorting, improved attribute organization, and persistent selection. ### Source excerpt Hello everyone! As Google Summer of Code 2026 comes to a close, it's time to summarize the work I've done over the summer on expanding the functionality of the Haiku Devices application. Overview Haiku's Devices application previously provided a basic list of connected hardware, but lacked the features necessary to function as a true management utility. My project aimed to transform Devices into a more capable hardware manager, allowing users to view detailed technical specifications and perform administrative tasks directly from the GUI. Over the course of the summer, I focused on implementing new visualization features, improving the user experience, and pulling more detailed hardware information directly from the system. Completed Objectives & Work Accomplished Here is a breakdown of what was accomplished this summer: Driver Mapping: Integrated the GUI with the kernel structures to display the active driver module name and its absolute path (/dev). This involved extending the device_manager module by adding a new device attribute and being able to fill that attribute when possible. Extract USB descriptors: Enhanced the application's ability to inspect USB devices. By utilizing the BUSBDevice API, the app now builds a tree with all USB attributes descending the USB hierarchy. We first loop through the configurations, then the interfaces, and finally the endpoints. The app can also display HID descriptors. State Management (Packaged Driver Blocking): Added a new GUI button to disable or re-enable packaged drivers. This required implementing the backend logic to read, modify, and write to the system's Packages configuration file. I also added safety checks to prevent users from accidentally disabling drivers essential to the system, and added warnings to guide the user through the process. Unit Tests: Although not explicitly part of my initial proposal, I took the initiative to write unit tests for the application. This was a fantastic learning experience for unders ## Batch Jobs for SparkClient: Submitting and Managing Spark Workloads from Python DevFeed: [Batch Jobs for SparkClient: Submitting and Managing Spark Workloads from Python]() Original publisher: [Read original article]() Author: Sameer Yadav Published: 2026-07-25T05:00:00Z Content type: tutorial Language: en Sources: [Kubeflow]() Topics: [Apache Spark](), [SDKs](), [Python](), [Kubernetes]() Tags: [batch](), [cleanup](), [gsoc](), [jobs](), [kubernetes](), [logs](), [pipelines](), [python](), [scheduled](), [sdk](), [spark]() ### AI overview This tutorial explains how the Kubeflow SDK's SparkClient supports submitting and managing batch Spark workloads on Kubernetes from Python. It covers script- and function-based jobs, lifecycle operations, log retrieval, cleanup, and the implementation's current boundaries. ### Source excerpt How the SparkClient SDK's new batch job APIs work under the hood -- submit_job(), FileJob/FuncJob, the lifecycle APIs, and log retrieval. ## GSoC Bluetooth Improvement Midterm Recap DevFeed: [GSoC Bluetooth Improvement Midterm Recap]() Original publisher: [Read original article]() Author: mohammedrattia Published: 2026-07-17T23:06:42Z Content type: article Language: en Sources: [Haiku Project]() Topics: [Bluetooth](), [Operating system](), [Embedded Software Dev]() Tags: [bluetooth](), [commands](), [devices](), [firmware](), [gsoc](), [gsoc2026](), [haiku](), [implementation](), [interface](), [midterm](), [recap](), [software]() ### AI overview This midterm recap describes improvements to Haiku's Bluetooth stack during a Google Summer of Code project. The work includes updating outdated Host-Controller Interface commands and events, implementing mandatory Bluetooth functionality, adding a setting for the device's friendly name, and adding support for canceling device inquiries. ### Source excerpt Hello! The GSoC's midterm (at least for me) has just passed, so I thought of making a recap post about the improvements I've made so far. I'll try to keep the post brief to make it easier for readers (foreshadowing: I realized that's impossible :P). I've already posted an introduction about me and the project. You can read it here if you haven't already. Host-Controller Interface (HCI) Commands and Events The Host-Controller Interface (HCI) is the specification for how the operating system (the host, in our case, is Haiku) communicates with the Bluetooth controller. The Bluetooth controller is basically the firmware on the Bluetooth chip. So, it's vital to implement at least most of the mandatory HCI commands and events from the Bluetooth specification for Bluetooth to function properly. HCI commands and events were mostly outdated, dating back to version 2.0 or 2.1, so updating them was the first step to get the Bluetooth stack back to life. The Bluetooth SIG provides an Implementation Conformance Statement (ICS) for HCI, which can be used as a checklist for what's mandatory and what's optional. So, I started by completing what Haiku's Bluetooth stack lacked from the mandatory list. I'll mention here the features that users will be using without getting into internal details, so please feel free to contact me if you want to know more. Set Friendly Name Honestly... I personally don't think this would affect the user experience that much, but it's not me who decides anyway. It was mandatory in HCI, so I implemented it in the Bluetooth settings. Anyway, users can now set any name they want for their Haiku's Bluetooth device. Thanks to Máximo for solving a crash this caused later on and to KitsunePrefecture for reporting the crash :) Cancel Inquiry Discovering Bluetooth devices in Haiku wasn't working before the GSoC application phase. It lacked the handling of critical events needed to understand modern devices. Some GSoC applicants had already fixed a great part of it ## \[GSoC 2026\] Modernizing Haiku's Bluetooth stack: Implementing support for HFP profile - Mid-Term Progress Report DevFeed: [\[GSoC 2026\] Modernizing Haiku's Bluetooth stack: Implementing support for HFP profile - Mid-Term Progress Report]() Original publisher: [Read original article]() Author: vighnesh-sawant Published: 2026-07-15T14:32:12Z Content type: article Language: en Sources: [Haiku Project]() Topics: [Bluetooth](), [Protocol (disambiguation)](), [systems](), [real-time](), [Streaming](), [USB](), [Kernel](), [interface]() Tags: [api](), [bluetooth](), [driver](), [gsoc](), [haiku](), [implementing](), [kernel](), [modernizing](), [progress-report](), [protocol](), [real-time](), [report](), [software](), [streaming](), [usb]() ### AI overview A GSoC 2026 progress report on modernizing Haiku's Bluetooth stack by adding groundwork for the Hands-Free Profile. Completed work includes isochronous USB endpoint support, SCO handling, kernel hooks, and SCO and RFCOMM protocol implementations. Planned work covers SPP, SDP, and the remaining HFP functionality. ### Source excerpt Introduction Hello again! It has been a fun journey since the beginning of GSoC. My project focuses on modernizing Haiku's Bluetooth stack, specifically adding support for the Hands-Free Profile (HFP). HFP is a profile that allows operating systems to interact with Bluetooth audio devices, such as headsets, for two-way voice calls and audio streaming. Today, I'll be sharing a progress report on the work I have completed till now, and will outline my plans for the remainder of the project. Progress So Far A significant portion of my work has been dedicated to laying the groundwork for the HFP profile. Because Haiku's Bluetooth stack previously lacked the necessary transport layers for real-time audio, I had to implement several underlying protocols. Here is a breakdown of the changes I've made: USB and Driver Support (Isochronous Endpoints): I started off by adding support for isochronous USB endpoints to the h2generic Bluetooth driver. Isochronous transfers are critical because they guarantee bandwidth and timely delivery of data, which is a requirement for streaming real-time audio. Following this, I implemented SCO (Synchronous Connection-Oriented) handling within h2transactions, along with the proper scheduling mechanism.. Kernel Hooks: I added the necessary hooks for SCO and HCI (Host Controller Interface) commands. Protocol Implementations (SCO and RFCOMM): I successfully added the core implementations for both the SCO and RFCOMM protocols. RFCOMM provides an emulated serial interface over L2CAP. It serves as the control channel for many higher-level profiles, including HFP. SCO handles the actual low-latency audio transmission needed for voice calls. What's Next? Short-term Goals: Serial Port Profile (SPP) The Serial Port Profile sits on top of RFCOMM and provides a standard way to send and receive data. Implement SPP API: I will be implementing the JSR82 API methods for SPP in the Bluetooth kit. Implementing the Hands-Free Profile (HFP) The remaining time wil ## \[GSoC 2026\] Midterm progress on the Devices application DevFeed: [\[GSoC 2026\] Midterm progress on the Devices application]() Original publisher: [Read original article]() Author: aquamatic123 Published: 2026-07-11T17:46:30Z Content type: article Language: en Sources: [Haiku Project]() Topics: [App](), [Hardware](), [GUI](), [USB](), [Bluetooth]() Tags: [app](), [bluetooth](), [gsoc](), [gui](), [haiku](), [hardware](), [midterm](), [software](), [usb]() ### AI overview A GSoC 2026 midterm report describes progress on revamping the Devices application, including improved hardware and driver information, a clearer tree-based interface, USB and HID descriptor support, and ongoing Bluetooth hardware scanning. ### Source excerpt Hello Everyone! I have officially reached the midterm mark of my GSoC project, revamping the devices application. Over the past few weeks, I have made a couple of changes extracting more hardware information and presenting it cleanly to the user. Here is a look at what has been accomplished so far. Extracting the device path and driver used The first goal of my GSoC project was to determine which driver is loaded for a device, and display the device path as well if existent. To do this, I worked with the device_manager to get the driver path. I managed to get a hold of this in the app with a dm_wrapper call, and then display it in DevicesView by creating the devices with that new attribute. For the device path, I also used the device_manager to add the published path as an attribute, that would get fetched in DevicesView as well. A Cleaner Layout I also had to make the device data easier to read. Previously, attributes were somewhat clumped together. I introduced a new tree-view layout that clearly separates Basic Information (like the device name) from the more advanced attributes. Building on that UI improvement, I also modified how attributes are displayed. Instead of just dumping all attributes into a single list, the application now generates an expandable tree structure. It looks for attributes containing a / in their name and parses them into nested folders, making complex configurations much cleaner to navigate. Extracting USB and HID Descriptors A major focus of the first half of this project was bringing the Devices app to include specific information like the command-line tool listusb -v. I implemented a new BuildUSBTree structure that maps a device to its hardware path (using a BUSBDevice object) and recursively goes through the configurations, interfaces, alternates, and endpoints of connected USB devices. This allows the GUI to display almost all the USB attributes that a user would normally need the terminal to see. I also added support for fetching H ## \[GSoC 2026\] Expanding the functionality of the Haiku Devices Application DevFeed: [\[GSoC 2026\] Expanding the functionality of the Haiku Devices Application]() Original publisher: [Read original article]() Author: aquamatic123 Published: 2026-05-08T02:10:41Z Content type: article Language: en Sources: [Haiku Project]() Topics: [Development](), [Hardware](), [Software Engineering](), [GUI](), [USB](), [Bluetooth](), [Microcontrollers]() Tags: [bluetooth](), [c](), [c-plus-plus](), [devices](), [gsoc](), [gui](), [haiku](), [hardware](), [microcontrollers](), [software](), [usb]() ### AI overview A GSoC 2026 project proposal to expand Haiku's Devices application into a hardware management utility. Planned work includes driver mapping, driver state controls, deeper USB and Bluetooth inspection, hardware-tree report export, and a bug-tracker shortcut. ### Source excerpt Introduction Hello! My name is Leo Rouleau, a first-year software engineering student at Polytechnique Montréal. I chose to apply for Haiku because of my interest in lower-level programming and operating systems. Having worked on projects involving microcontrollers and custom interpreters in C, C++, and Java, I've found systems-level development to be the most engaging challenge. Project Overview Haiku's current Devices application provides a basic list of connected hardware, but it lacks the features necessary to function as a true management utility. This project aims to transform Devices into a full-fledged hardware manager, allowing users to view detailed technical specifications and perform administrative tasks directly from the GUI. Goals Driver mapping Display the active driver module name and its absolute path for the device (/dev). State management Implement a graphical toggle to block or blacklist drivers with warnings for system restarts USB and Bluetooth support Increase the application's ability to inspect dynamic buses. For example, USB devices will display deep interface descriptors and HID report formats, and Bluetooth would automatically be populated correctly within the tree. Compatibility Report Develop a serialization logic to export the system's hardware tree into a standardized report. Bug Tracker Create a shortcut to open the Haiku Trac bugtracker with a report containing the hardware specifications of a selected device. Conclusion This was a blog to introduce myself to the community and the project I will be taking on this summer for GSoC 2026. Thank you for reading! ## \[GSoC 2026\] Bluetooth: HCI Improvements & HID Profile | Haiku Project DevFeed: [\[GSoC 2026\] Bluetooth: HCI Improvements & HID Profile | Haiku Project]() Original publisher: [Read original article]() Author: mohammedrattia Published: 2026-05-03T13:46:03Z Content type: article Language: en Sources: [Haiku Project]() Topics: [Bluetooth](), [Computer science](), [Development](), [Software Engineering](), [Operating system]() Tags: [2026](), [bluetooth](), [computer-science](), [google-summer-of-code](), [gsoc](), [gsoc2026](), [haiku](), [hci](), [hid](), [improvements](), [profile](), [programming](), [project](), [software](), [software-engineer](), [software-engineering](), [systems]() ### AI overview A GSoC 2026 proposal for Haiku aims to modernize the operating system's Bluetooth stack and implement the Bluetooth HID profile. The planned work includes completing HCI commands, improving pairing and Link Key persistence, and handling disconnection and timeout events. ### Source excerpt Hello! I'm Mohammed R. Attia, a 2nd-year Computer Science Student. I've been accepted into Google Summer of Code (GSoC) 2026 with Haiku, with my proposal titled "Modernizing Haiku's Bluetooth Stack: HCI Completion and HID Profile Implementation." About Me I consider myself a competitive programmer and a software engineer. I haven't decided on a specific specialization in software engineering just yet; rather, I'm interested in systems development and low-level programming. You can check my GitHub for more information about my latest projects. I go by the handle mohammedrattia in many places on the internet, so feel free to reach out :). How did I get here? I first learned about Haiku while searching for GSoC organizations to contribute to. It was my first time learning about a desktop operating system other than the famous trio: Windows, macOS, and Linux. So, I started by reading the GSoC guide and joining IRC. I remember that the process was smooth because the guide contained everything, and people on IRC were welcoming and supportive. Then, I started working towards building Haiku, and I got my first commit merged into Haiku after several days. Current Goals The main goal of my proposal in GSoC is to modernize the Bluetooth stack. Currently, the Bluetooth stack in Haiku can't communicate effectively with modern Bluetooth devices because of the outdated standards it uses. However, making the Bluetooth core perfectly align with modern standards won't benefit Haiku users because it would still need a Bluetooth Profile to perform a useful task. One of the most common uses of Bluetooth is Human Interface Devices (HID) (e.g., keyboards and mice). Accordingly, this project will build the HID Bluetooth profile to provide useful functionality for Haiku users. The following three sub-sections contain a brief specification for the goals of the project from my GSoC proposal. Modern HCI Event & Command Handling Build upon the recent SSP/EIR groundwork by implementing the remai ## The Journey Begins: Meet the 2026 GSoC Contributors! DevFeed: [The Journey Begins: Meet the 2026 GSoC Contributors!]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-04-30T18:30:00Z Content type: news Language: en Sources: [Google Open Source Blog]() Topics: [Google](), [Open Source](), [Development]() Tags: [2026](), [community](), [contributors](), [google-summer-of-code](), [gsoc](), [mentoring](), [open-source](), [program](), [student-programs]() ### AI overview Google Summer of Code welcomes its 1,141 contributors for 2026. The article reports 15,245 applicants from 131 countries, 23,371 proposals, 184 mentoring organizations, and more than 2,000 mentors and organization administrators. It also describes the 3.5-week Community Bonding period before coding begins on May 25. ### Source excerpt by Stephanie Taylor, Mary Radomile & Lucila Ortíz, Google Summer of Code A warm welcome to the 1,141 Contributors of Google Summer of Code (GSoC) 2026! We are excited to start this new edition alongside our 184 mentoring orgs. Organizations reviewed a record-breaking 23,371 proposals to find the best matches for their communities. 2026 Application Statistics: 15,245 applicants from 131 countries submitting a total of 23,371 proposals Over 2,000 mentors and org admins What's Next? Before the first line of code is written, there is Community Bonding. This 3.5-week GSoC tradition is about more than just tool configuration; it's about immersion. It's a dedicated space for Contributors to master the codebase, align with community standards, and understand the 'why' behind their projects. By the time the coding period begins, every Contributor is ready to turn project fundamentals into real-world impact. The official coding period begins on May 25. For our contributors, this period represents a deep dive into collaborative development, offering the chance to learn new tools and contribute to the heartbeat of open source projects. Thank you, Mentors! Finally, we want to express our deepest gratitude to our phenomenal Mentors and Org Admins. As AI profoundly shifts the landscape of open source communities, GSoC is no exception. Your patience, grit, and tireless volunteer efforts are the heartbeat of this program, ensuring its continued success as we welcome a new generation of contributors into the open source ecosystem. ## Announcing QEMU Google Summer of Code 2026 internships DevFeed: [Announcing QEMU Google Summer of Code 2026 internships]() Original publisher: [Read original article]() Published: 2026-02-20T07:00:00Z Content type: release Language: en Sources: [QEMU]() Topics: [qemu](), [Google](), [Open Source]() Tags: [2026](), [google-summer-of-code](), [gsoc](), [internship](), [internships](), [open-source](), [qemu](), [remote]() ### AI overview QEMU announces its participation in Google Summer of Code 2026, offering paid remote internships from May through August. Interns will work with experienced QEMU developers and contribute through the project's standard open source process. ### Source excerpt QEMU is participating in Google Summer of Code once again! Google Summer of Code is an open source internship program with internships running May through August. Would you like to experience contributing to an open source project? This paid remote work internship opportunity is a great way to get involved! ## QEMU at Google Summer of Code Mentor Summit 2025 DevFeed: [QEMU at Google Summer of Code Mentor Summit 2025]() Original publisher: [Read original article]() Author: Stefano Garzarella Published: 2025-11-20T08:00:00Z Content type: news Language: en Sources: [QEMU]() Topics: [qemu](), [Google](), [Open Source](), [macOS](), [Rust](), [POSIX]() Tags: [conferences](), [event](), [germany](), [google-summer-of-code](), [gsoc](), [internships](), [macos](), [open-source](), [posix](), [qemu](), [rust]() ### AI overview A report on the 2025 Google Summer of Code Mentor Summit in Munich, where QEMU mentors discussed open source challenges, mentorship practices, and related projects. The article also describes a GSoC project extending Rust crates for vhost-user devices on macOS and BSD. ### Source excerpt The Google Summer of Code (GSoC) Mentor Summit 2025 took place from October 23rd to 25th in Munich, Germany. This event marks the conclusion of the annual program, bringing together mentors from all over the world. QEMU had another successful year with several interesting projects (details on our organization page), and it was a pleasure for me to represent the QEMU community at the summit, joining mentors from over 100 open source organizations to discuss the program, share experiences, and talk about open source challenges. ## Google Summer of Code 2025 Results DevFeed: [Google Summer of Code 2025 Results]() Original publisher: [Read original article]() Author: Thomas Dinges Published: 2025-10-21T09:37:52Z Content type: article Language: en Sources: [Blender]() Topics: [Google](), [Code](), [Testing](), [test-coverage](), [cpu](), [GPU]() Tags: [2025](), [code](), [cpu](), [general-development](), [google](), [gpu](), [gsoc](), [technical](), [test-coverage](), [testing]() ### AI overview Blender's Google Summer of Code 2025 results article reviews work by eight contributors on the compositor, Video Sequence editor, mesh editing, sculpting, regression test coverage, and the Flamenco render manager. It notes that most changes had already been merged and were planned for Blender 5.0. ### Source excerpt See the outcome of the eight projects to be part of Google Summer of Code 2025. ## A Summer with Mobian: The Story of Tweakster (GSoC '25) DevFeed: [A Summer with Mobian: The Story of Tweakster (GSoC '25)]() Original publisher: [Read original article]() Author: Mobian team Published: 2025-08-23T08:34:47Z Content type: opinion Language: en Sources: [Mobian's Blog]() Topics: [Mobile](), [Linux](), [Refactoring](), [Debian](), [Kernel](), [systemd]() Tags: [2025](), [boot](), [debian](), [gsoc](), [kernel](), [linux](), [mobile](), [refactoring](), [systemd]() ### AI overview A Google Summer of Code 2025 contributor describes refactoring tweakster for the Mobian project. The revised system daemon identifies a device, reads device-specific configuration, builds and installs a Debian package containing the required tweaks, and runs as a systemd service on first boot. ### Source excerpt This summer, I had the incredible opportunity to work with the Mobian project for Google Summer of Code 2025. My goal was to continue the work on tweakster to a point where it could integrate smoothly with the Mobian ecosystem. This post is a summary of my work, the challenges I faced, and what's next for tweakster. The Root Problem Since the start of Mobian in 2020, the goal has always been clear: have one bootable image for all kinds of non-x86 devices. That's much harder than it sounds. There are subtle but crucial hardware differences across devices that require specific tweaks, making the mission of achieving a Universal Kernel on a system level very difficult. Another pain point is the significant number of new non-x86 Linux-capable devices that have hit the market in the past few years, especially ARM64 laptops, mobile phones, and tablets. Maintaining a device-specific package for each one is impractical. It would take us far away from the "universal system" dream and make Mobian devs' jobs even harder! How It All Started After a lot of thought from the team and my mentor, Arnaud (@a-wai), they came up with tweakster, the hero of our story. Simply put, tweakster is a system daemon that identifies the device it's running on by checking the device-tree compatible property. It then determines the necessary tweaks by reading a pre-prepared config file, processes tweaks files, then creates symlinks to the resulting files into the system. The first attempt in 2022, packaged for Debian, saw some improvements over the years, leading to its latest form in 2024. A Change in Plans It turned out the first attempt was a bit over-engineered. It needed a complete refactoring, following the philosophy of starting simple and growing methodically. This is where I came in. Working hand-in-hand with my mentors, Arnaud (@a-wai) and Jarrah (@Undef), we forged the new vision of tweakster, so it will eventually make it easier to ship Mobian to new devices. The new approach is simple ## Announcing QEMU Google Summer of Code 2025 internships DevFeed: [Announcing QEMU Google Summer of Code 2025 internships]() Original publisher: [Read original article]() Published: 2025-03-06T07:00:00Z Content type: article Language: en Sources: [QEMU]() Topics: [qemu](), [Open Source](), [Development]() Tags: [contributions](), [contributors](), [google-summer-of-code](), [gsoc](), [internships](), [open-source](), [qemu](), [remote]() ### AI overview QEMU announces its participation in Google Summer of Code 2025. The article explains the paid remote open-source internships, mentorship, application process, project selection, and application dates. ### Source excerpt QEMU is participating in Google Summer of Code again this year! Google Summer of Code is an open source internship program that offers paid remote work opportunities for contributing to open source. Internships run May through August, so if you have time and want to experience open source development, read on to find out how you can apply. ## Blog: Halfway Through GSoC 2024: My Progress and Plans with Falco DevFeed: [Blog: Halfway Through GSoC 2024: My Progress and Plans with Falco]() Original publisher: [Read original article]() Published: 2024-07-24T00:00:00Z Content type: article Language: en Sources: [Falco - Falco](), [Falco - The Falco blog]() Topics: [Falco](), [benchmarking](), [Testing](), [ci]() Tags: [benchmarking](), [container](), [continuous-integration](), [falco](), [gsoc](), [mentorship](), [midterm](), [testing](), [yaml]() ### AI overview A GSoC 2024 mentee describes progress improving Falco's event-generator for testing and benchmarking. The project includes declarative YAML-based Falco rule testing, a container runner, and planned CI pipelines to assess threat-detection correctness and performance. ### Source excerpt Hello Falco community, I'm Kiriti, a current GSoC mentee under Falco Security. I have been working diligently to improve the testing and benchmarking capabilities of Falco's event-generator project. Now that we've reached the midterm of GSoC, I'm eager to share the journey so far. In this blog, I'll delve into the details of my contributions, particularly focusing on two key PRs that have been merged, and outline my plans for the remainder of the program. My Project: Enhancing Falco's Event-Generator The event-generator is a vital utility within the Falco ecosystem, designed to test Falco's detection capabilities. My Google Summer of Code project focuses on upgrading the event-generator to enhance its testing and benchmarking capabilities, reliability, and consistency. Additionally, I am developing new Continuous Integration (CI) pipelines based on the upgraded event-generator. The ultimate goal is to evolve the event-generator into the standard tool for systematically assessing the correctness and performance of Falco's threat detection capabilities during every release and development cycle. My Journey So Far: Before being selected for GSoC, I contributed to the event-generator repository. I am grateful to Leonardo Grasso and Federico Di Pierro, who played a vital role in getting my PRs merged during the pre-GSoC contribution phase. These contributions helped me understand the event-generator codebase. I am also thankful to my mentors, Jason Dellaluce and Aldo Lacuku, for selecting me as a GSoC mentee. I will share my complete story of getting selected to GSoC in future. After my selection, Jason, Aldo, and I collectively designed a plan to enhance the event-generator. The community bonding period was crucial in designing and understanding the implementation plan. You can view our idea here, which we will implement during this GSoC period. Once the coding period began, we managed to merge two key PRs before the midterm. These PRs partially added support for testin ## Welcome GSoC 2021 Students! DevFeed: [Welcome GSoC 2021 Students!]() Original publisher: [Read original article]() Published: 2021-05-18T00:00:00Z Content type: news Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [Windows](), [Library](), [Hardware](), [Concurrency]() Tags: [concurrency](), [free](), [google-summer-of-code](), [gsoc](), [mentoring](), [open-source](), [os](), [processor](), [react](), [reactos](), [student](), [win32](), [winapi](), [windows]() ### AI overview The ReactOS Project is participating in Google Summer of Code 2021 and selected He Yang and Justin Miller for projects involving RunOnceEx support in iernonce.dll and Symmetric Multiprocessing support. The work is intended to improve compatibility, hardware usability, and concurrency handling in ReactOS. ### Source excerpt Another year, another round of Google Summer of Code! The ReactOS Project is participating in Google Summer of Code 2021 and welcomes the selected students. He Yang is a successful student from GSoC 2020, who is going to continue his dive into user-mode ReactOS this year by working on iernonce.dll. That library is responsible for RunOnceEx, a prominent Windows feature to run multiple commands once after a system reboot. Implementing that feature will benefit software depending on it. ## Porting Syzkaller to ReactOS Final Evaluation - GSoC 2020 DevFeed: [Porting Syzkaller to ReactOS Final Evaluation - GSoC 2020]() Original publisher: [Read original article]() Published: 2020-09-01T00:00:00Z Content type: opinion Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [Code](), [Kernel](), [virtualization](), [x86]() Tags: [free](), [gsoc](), [kernel](), [network](), [open-source](), [os](), [porting](), [project](), [react](), [reactos](), [ssh](), [virtualization](), [win32](), [winapi](), [x86]() ### AI overview This wrap-up reports on a three-month GSoC project to port Syzkaller to ReactOS. The work produced a working ReactOS port, used existing kernel sanitizers, fixed the main executor, and added a proof of concept for fuzzing ntdll calls. Remaining work included kernel code coverage, Syzbot integration, upstreaming, and network functionality. ### Source excerpt Hello everyone, I am Suraj K Suresh, the one working on the GSoC project of "Porting Syzkaller to ReactOS". It's been 3 whole months since GSoC has begun and this is the last evaluation period. During the last 3 months, I worked on various parts of Syzkaller and getting them up and running on ReactOS and Windows with the help of my Mentors. This blog post will be a wrap-up post of the GSoC project. ## Detect kernel information disclosure by Bochspwn-reloaded - GSoC 2020 - Final report DevFeed: [Detect kernel information disclosure by Bochspwn-reloaded - GSoC 2020 - Final report]() Original publisher: [Read original article]() Published: 2020-08-31T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [Kernel](), [bug](), [Filesystems](), [Assembly]() Tags: [bugs](), [free](), [gsoc](), [kernel](), [open-source](), [os](), [patches](), [react](), [reactos](), [win32](), [winapi]() ### AI overview A GSoC 2020 final report on finding and patching memory-disclosure bugs in ReactOS, including kernel detection work using bochspwn-reloaded. The author reports 12 bugs with patches found and notes that further uninitialized-memory reports may include false positives. ### Source excerpt After 3 months since the last blog, I found and pull the patches of 12 memory disclosure bugs: [NTOS:PS] Fix stack memory disclosure in PsGetContextThread: merged [Win32SS][USER] Fix stack memory disclosure in NtUserBuildPropList: merged [MOUNTMGR] Fix pool memory disclosure in QueryPointsFromMemory: merged [Win32SS][GDI] Fix pool memory disclosure in NtGdiGetGlyphOutline: merged [DRIVERS] Fix pool memory disclsoure in CreateDiskDeviceObject of disk driver: closed [NTGDI] Fix stack memory disclosure in NtGdiGetTextMetricsW: merged [NTOS:KE] Fix stack memory disclosure in KiInitializeUserApc: merged [NTOS:IO] Fix pool memory disclosure in IopQueueTargetDeviceEvent: merged [Win32SS][GDI] Fix pool memory disclosure in NtGdiGetOutlineTextMetricsInternalW: merged [WIN32SS][NTUSER] Fix uninitialized memory cause memory disclosure used for KeUserModeCallback: merged [FILESYSTEMS] Fix pool memory disclosure in filesystem drivers supporting FS_INFORMATION_CLASS. ## Rapps Enhancement final report - GSoC 2020 DevFeed: [Rapps Enhancement final report - GSoC 2020]() Original publisher: [Read original article]() Published: 2020-08-29T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [win32](), [Command-line interface](), [Refactoring](), [GUI]() Tags: [command-line](), [free](), [gsoc](), [open-source](), [os](), [react](), [reactos](), [refactor](), [win32](), [winapi]() ### AI overview A GSoC 2020 final report describes improvements to ReactOS RAPPS, including screenshot and icon support, UI and list-view refactoring, command-line options, settings storage changes, and remaining unfinished work. ### Source excerpt Hi, I'm He Yang (@kernel.bin), one of the GSoC-2020 students of ReactOS. How time flies, three months have passed and now GSoC is coming to an end. During the last three months, I've been working on rapps, and I've made some small progress on it: improving rapps by increasing it's functionality, stability, and make the code more well-organized. During GSoC, I've acquired a lot of coding skills and knowledge about Win32. ## Rapps Enhancement stage 1 & 2 - GSoC 2020 DevFeed: [Rapps Enhancement stage 1 & 2 - GSoC 2020]() Original publisher: [Read original article]() Published: 2020-08-08T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [App](), [ui](), [Refactoring]() Tags: [apps](), [free](), [gsoc](), [open-source](), [os](), [react](), [reactos](), [refactoring](), [screenshot](), [ui](), [win32](), [winapi]() ### AI overview A GSoC 2020 progress report on ReactOS Application Manager (RAPPS) covering work completed in stages 1 and 2. The changes include screenshot and icon support, list-view and toolbar improvements, UI refactoring, bug fixes, and handling for WOW64 registry behavior. The post also outlines planned work on downloads and command-line support. ### Source excerpt Hi, I'm He Yang (@kernel.bin), one of the GSoC-2020 students of ReactOS. Two months have passed since GSoC started, and during these two months, I've made some progress on ReactOS Application Manager (RAPPS), the project I'm working on. In this blog, I will list out what I've accomplished in these two months, and what I'm planning to do in the next month. The work I've done in Stage 1&2 Stage 1 During stage 1, I mainly focused on screenshot and icon support and various small improvements. ## Porting Syzkaller to ReactOS - GSoC 2020 DevFeed: [Porting Syzkaller to ReactOS - GSoC 2020]() Original publisher: [Read original article]() Published: 2020-06-04T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [Kernel](), [Testing](), [Google]() Tags: [crashes](), [free](), [gsoc](), [kernel](), [linux](), [open-source](), [os](), [porting](), [react](), [reactos](), [testing](), [win32](), [winapi]() ### AI overview A ReactOS GSoC student describes porting Syzkaller, a Google coverage-guided kernel fuzzer, to ReactOS. The work includes restoring Windows x64 and x86 support, adapting required synchronization functions, and investigating a zombie executor process. ### Source excerpt Hey, I am Suraj K Suresh (@Freakston), one of the GSoC students of ReactOS. This is the first time I've applied for GSoC and my mentors for the project are Victor Perevertkin and Timo Kreuzer. My project is "Porting Syzkaller to ReactOS". The project is getting one of the most famous Linux fuzzers to fuzz ReactOS. The project will lead to improvement of the kernel codebase by detecting code crashes. ## Detect kernel information disclosure by Bochspwn-reloaded - GSoC 2020 - First week DevFeed: [Detect kernel information disclosure by Bochspwn-reloaded - GSoC 2020 - First week]() Original publisher: [Read original article]() Published: 2020-06-04T00:00:00Z Content type: tutorial Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [Instrumentation](), [Visual Studio](), [Assembly](), [Bash](), [Vcpkg]() Tags: [bash](), [free](), [gsoc](), [instrumentation](), [open-source](), [os](), [react](), [reactos](), [studio](), [vcpkg](), [win32](), [winapi]() ### AI overview A ReactOS GSoC student reports the first week of a project using bochspwn-reloaded to detect kernel information disclosure and uninitialized memory use. The article describes changes to stack-trace formatting, source lookup for inline and non-inline functions, and compiling the tool with Visual Studio 2019. ### Source excerpt Introduction Hello, I am Nguyen Trung Khanh (@khanhnt) from Vietnam and I am one of the GSoC students of ReactOS. My project is running ReactOS on bochspwn-reloaded to list and fix all the bugs which were found by the tool. Additionally, I have a week to implement detection of uninitialized memory use. The first week Before GSoC, I did compile bochspwn-reloaded and run ReactOS on it so my work in the first week is pretty easy. [Next page]()