This report covers hrev57802 through hrev57900.
The major item I spent the most time on last month was general system performance and stability. This involved a number of changes to the kernel as well as to various parts of userland that pretty much all applications use in one way or another.
This paves the way for more FD types to be introduced by drivers without explicit kernel support for them.
So, theoretically, a correctly-coded driver could introduce such things as team and port FDs?
Port FDs are something we should introduce in the kernel itself, as I’ve mentioned before.
I don’t think there is any reason to introduce team FDs, whether in the kernel or in drivers. The concept of having “FDs” for absolutely everything rather than distinct object types is a Linuxism. We already support EVFILT_PROC in kqueue which is the BSD-style way of dealing with this. And likewise, if we need it, we should add EVFILT_SIGNAL rather than signalfd and so on.
Exactly why it should be handled by an external driver for users who somehow want it instead of being introduced to the mainline kernel.
But with the ability to create arbitrary FDs, coupled with the Debugger API’s ability to intercept syscalls, it is now easier to develop a Linux compatibility layer… for those who dare.
Ah, yeah, that might be an interesting usecase indeed. But a major disadvantage here is that the FreeBSD Linuxulator can support GUI apps because FreeBSD also uses X11. We don’t (Xlibe doesn’t implement the X11 protocol, only the library). I guess the in-process Wayland server might be of use… but it still sounds like a long shot (given how much effort it appears to be to maintain the Linuxulator on FreeBSD.)
A big thanks to all who contributed again, it certanly has been busy (and we’re not there yet, but getting close to beta5), also a big thanks to all who reported bugs, this also paved the way to Haiku’s current situation. Kudos to all! 
Team FD allows to reliably reference one team from another that is not parent team without use after free risk.
Thank you everyone for your hard work. It’s an impressive amount of work getting done and that in a month where you would expect most people to be outside in the sun.
Auh, yeah, …
this was a long run of coding sprint as I witnessed on Gerrit repo !
Thank you to all of you for shaping a more reliable Haiku for daily driver kind of persons, like me 
It was quite impressive to see the tons of patches that continued until now … so next report will be really interesting too - 
It’s a month that’s quieter than usual at the paid job, and also too hot to be outside in the sun. So, more time and energy left for Haiku things 
Haiku development is practically solar powered. 
Great work, people. Really looking forward to Beta 5.
Me too, WHEN???
That’s fair, living as far north as I do, it’s easy to forget that the rest of Europe is getting roasted.
What a massive stack of important changes! Hat off and big THANK YOU.