It gives me great pleasure to announce the second round of the expanded Red Hat Collaboratory awards. This year we funded ten collaborative projects and nine speculative ones for $2.3 million, including a mix of new projects and continuations of the ones we supported in 2022.
Like everything we engage in at Red Hat Research, these projects are intended to push research ideas into open source, where they can develop into working code. We’ve now had this happen with at least three projects: Morphuzz (the QEMU fuzzer), Ceph storage caching, and the Unikernel project. Our projects on software and hardware co-design will soon follow. It’s not easy finding engineers with time and energy to invest in these things, nor is it easy to convince researchers they should spend a little extra effort to make their results consumable by an open source community. But when we pull it off, the results make the effort very much worth it.
Another place we find interesting collaborative projects is in all things related to edge and IoT, particularly where wireless is involved. For this issue, we start with an interview with Abhimanyu (Manu) Gosain, who leads the Institute of the Wireless Internet of Things at Northeastern University. It’s crucial to keep the data from an advanced factory or a research experiment local to the work, for both practical and regulatory reasons. Gosain talks about using AI inference on the user and control plane of fast wireless networks to make decisions in milliseconds—no time to send the data to the cloud for processing. What’s more, the code making these decisions needs to be editable by ordinary software engineers, so there are now Python APIs to let cloud developers write apps that run in these situations.
You can see a practical example of this in the second IoT article in this issue. Research at Czech Technical University demonstrates automated testing of IoT devices used to monitor soldiers’ health on the battlefield. Dubbed PatrIoT, the system researchers co-developed with Red Hat automates testing IoT devices in simulated unstable conditions, like those found during a natural disaster or on the battlefield.
Finally, as software does more and more, it is more and more important to help developers write better software. This is the motivation for Rust language, a compiled, high-performance language with the flexibility of low-level C, but with rules in place to prevent the common bugs even good C developers are prone to write. Rust does a really good job of providing guardrails to prevent unsafe code without being too constrained to be effective. However, there are times—writing API bindings for C code or device drivers, for example—when Rust programmers need to do unsafe things, and the guardrails are turned off. Our article on our joint project with Columbia professor Baishaki Ray describes Yuga, a code analyzer for Rust that specifically looks for errors in code flagged unsafe—the kind of code that would cause a real Rust program to crash, or worse. Tools like Yuga are essential for Rust to realize its potential as a complete upgrade from our current language tool bag, and we’re proud to be funding its development.