Those sources get ‘thrown over the wall’ upon release, very often never to be touched again. They are full of proprietary code (binary blobs), dirty hacks, ancient kernels, and all manner of other garbage that will never see the light of day in mainline Linux. All of which is very similar to the situation on Android, if you know anything about that.
In fact, if not for projects like Armbian, our SBCs would likewise become throwaway devices, too — just like your Android — in pretty short order. That is, if you ever even got them to work in the first place.
While things look reasonably normal, we _are_ getting pretty late in the release, and we still have a number of known regressions. They don't seem all that big and scary, but some of them were reported right after the rc1 release, so they are getting a bit long in the tooth. I'd hate to have to delay 5.17 just because of them, and I'm starting to be a bit worried here. I think all the affected maintainers know who they are.
First, we want to thank everyone who participated by sending in their papers. We received a healthy response of twenty-two papers from members of the community. The papers weighed-in on the multiple areas of interest we had indicated in our announcement. Using an anonymous review process, we concluded there were five papers that would be best suited to inform the community and foster critical conversations to help guide our actions in the search for solutions.
One of the submissions published was from Policy Fellow at Software Freedom Conservancy, Bradley M. Kuhn; that organization has announced the formation of a committee to "develop recommendations and plans for a Free and Open Source Software (FOSS) community response to the use of machine learning tools for code generation and authorship". A public ai-assist mailing list has been set up for discussions. "The inaugural members of the Committee are: Matthew Garrett, Benjamin Mako Hill, Bradley M. Kuhn, Heiki Lõhmus, Allison Randal, Karen M. Sandler, Slavina Stefanova, John Sullivan, David ‘Novalis’ Turner, and Stefano ‘Zack’ Zacchiroli."
In theory, any unsoundness issue potentially undermines Rust's promise of reliability. We want, by the end of this year, to have a clear understanding of how each of those I-unsound issues came to be. We are looking into systematically detecting such issues and whether we can deploy mitigations or fixes for entire classes of issues, instead of addressing them on a case by case basis.
Preventing stack overflows from corrupting unrelated memory contents is the goal of VMAP_STACK, which we are enabling for 32-bit ARM as well. When VMAP_STACK is enabled, kernel mode stacks are allocated from the kernel heap as before, but mapped into a different part of the kernel's address space, and surrounded by guard regions, which are guaranteed to be kept unpopulated. Given that accesses to such unpopulated regions will trigger an exception, the kernel's memory management layer can step in and terminate the program as soon as a stack overflow occurs, and prevent it from causing memory corruption.
Linutronix is comprised of a team of highly qualified and motivated employees with a wealth of experience and involvement in the ongoing development of Linux. Led by CEO Heinz Egger and CTO Thomas Gleixner, Linutronix is the architect of PREEMPT_RT (Real Time) and the leading technology provider for industrial Linux. Gleixner has been the principal maintainer of x86 architecture in the Linux kernel since 2008.
The plan is evidently to continue to run Linutronix as an independent company rather than absorbing it into Intel.