The members of the kernel security team are not allowed to tell their employers anything that happens on the security list. They are there as individual members, not as employees. And try to define "major distros" in a…
They hide structures very easily, allowing programmers to accidentally put them on the stack or use them as parameters in functions where they shouldn't be doing so. By forcing "struct" on the name, it makes it more…
The amount of resources and other stuff that the LF provides to the Linux kernel community has increased over the years, including last year. Just because new people are brought in with new projects (that the LF member…
Did anyone think to actually ask the developer who is maintaining the LTS kernel versions why he made that change (back in February?), i.e. me? {sigh} No, I guess that would take too much effort, and wouldn't result in…
No, the only rust code accepted into any released kernels is basic framework infrastructure so that someday, maybe, in the future, real functionality could be written in rust. There are many out-of-tree examples of rust…
This already happens today at many companies. I write a few of these a year for companies that I do not work at, and have been for the past decade or so. It's not unusual and the companies that recognize that having…
Corporate guys "manage me"? Have you talked to any corporate guys who have actually tried that and discussed the results with them? :)
Yes, and because of that, we created a new process for those types of issues (i.e. broken hardware problems that need more coordination.) That process is documented at…
I've described how we (the kernel security team) handles this type of things many times, and even summarized it in the past here: http://www.kroah.com/log/blog/2018/02/05/linux-kernel-releas... Scroll down to the…
While I did drop by a lot, you aren't describing me, but rather another Linux kernel developer who worked at IBM in our group at the time who is by far more brilliant and smarter than I. I've never smoked, and at that…
I'm not understanding the question here at all, sorry, can you please rephrase it? And if you have questions about how this happened, look at the source for when it was merged, it's all there for everyone to review :)…
The person who started udev (i.e. me), and the person who did the majority of the work on udev to make it into the proper solution for everyone (i.e. Kay Sievers), both agreed that it made more sense to move it into the…
Off the top of my head, no. The big "downside" is that it takes more work on the patch submitter side. But the benefits in the end are almost always more than worth it (easier reviewer time, easier time to track down…
Merge the portions that you know are correct and will have no affect on anyone else now, which makes future work easier as you do not have to keep those "working" commits up to date. We do this all the time with kernel…
Thanks for the support. I also now have submitted a patch series that reverts the majority of all of their contributions so that we can go and properly review them at a later point in time:…
Why is it "excessive"? We are running 30+ fixes a day in these kernel releases, who would benefit if we delayed in getting those known-bug/security fixes out to the world quickly and properly tested (as we are currently…
So you want us to just stop fixing bugs and pushing out those fixes to users? That feels risky, if you do not want to upgrade to solve known problems, that's fine, feel free to skip upgrades. But why would you want to…
Time to get a new ISP? :)
And what would that help solve?
We have so many different CI systems running on the kernel on a hourly basis. We have the 0-day bot from Intel that runs so many things on all developer trees. We have kernelci running on many many different hardware…
Simplest thing to do, just run Linus's latest releases (the -rc releases), or from his git tree, on your machine and report any problem. Second-simplest thing to do is to run the linux-next branch/tree on your machines…
If people don't report bugs, we don't know they are there as it "works for me!". This isn't "negativity", this is people not understanding how the process works :) And you're welcome!
Where in the current CI that we have today is lacking that needs to be improved? We always want more testing and testers, what is preventing everyone from helping with this?
I get a vacation? Hah!
Everyone gets older, the alternative isn't as attractive :) Seriously, the kernel averages about 200-250 new contributors every release (i.e. every 2 1/2 months). We are not starved for new contributors at the moment at…
The members of the kernel security team are not allowed to tell their employers anything that happens on the security list. They are there as individual members, not as employees. And try to define "major distros" in a…
They hide structures very easily, allowing programmers to accidentally put them on the stack or use them as parameters in functions where they shouldn't be doing so. By forcing "struct" on the name, it makes it more…
The amount of resources and other stuff that the LF provides to the Linux kernel community has increased over the years, including last year. Just because new people are brought in with new projects (that the LF member…
Did anyone think to actually ask the developer who is maintaining the LTS kernel versions why he made that change (back in February?), i.e. me? {sigh} No, I guess that would take too much effort, and wouldn't result in…
No, the only rust code accepted into any released kernels is basic framework infrastructure so that someday, maybe, in the future, real functionality could be written in rust. There are many out-of-tree examples of rust…
This already happens today at many companies. I write a few of these a year for companies that I do not work at, and have been for the past decade or so. It's not unusual and the companies that recognize that having…
Corporate guys "manage me"? Have you talked to any corporate guys who have actually tried that and discussed the results with them? :)
Yes, and because of that, we created a new process for those types of issues (i.e. broken hardware problems that need more coordination.) That process is documented at…
I've described how we (the kernel security team) handles this type of things many times, and even summarized it in the past here: http://www.kroah.com/log/blog/2018/02/05/linux-kernel-releas... Scroll down to the…
While I did drop by a lot, you aren't describing me, but rather another Linux kernel developer who worked at IBM in our group at the time who is by far more brilliant and smarter than I. I've never smoked, and at that…
I'm not understanding the question here at all, sorry, can you please rephrase it? And if you have questions about how this happened, look at the source for when it was merged, it's all there for everyone to review :)…
The person who started udev (i.e. me), and the person who did the majority of the work on udev to make it into the proper solution for everyone (i.e. Kay Sievers), both agreed that it made more sense to move it into the…
Off the top of my head, no. The big "downside" is that it takes more work on the patch submitter side. But the benefits in the end are almost always more than worth it (easier reviewer time, easier time to track down…
Merge the portions that you know are correct and will have no affect on anyone else now, which makes future work easier as you do not have to keep those "working" commits up to date. We do this all the time with kernel…
Thanks for the support. I also now have submitted a patch series that reverts the majority of all of their contributions so that we can go and properly review them at a later point in time:…
Why is it "excessive"? We are running 30+ fixes a day in these kernel releases, who would benefit if we delayed in getting those known-bug/security fixes out to the world quickly and properly tested (as we are currently…
So you want us to just stop fixing bugs and pushing out those fixes to users? That feels risky, if you do not want to upgrade to solve known problems, that's fine, feel free to skip upgrades. But why would you want to…
Time to get a new ISP? :)
And what would that help solve?
We have so many different CI systems running on the kernel on a hourly basis. We have the 0-day bot from Intel that runs so many things on all developer trees. We have kernelci running on many many different hardware…
Simplest thing to do, just run Linus's latest releases (the -rc releases), or from his git tree, on your machine and report any problem. Second-simplest thing to do is to run the linux-next branch/tree on your machines…
If people don't report bugs, we don't know they are there as it "works for me!". This isn't "negativity", this is people not understanding how the process works :) And you're welcome!
Where in the current CI that we have today is lacking that needs to be improved? We always want more testing and testers, what is preventing everyone from helping with this?
I get a vacation? Hah!
Everyone gets older, the alternative isn't as attractive :) Seriously, the kernel averages about 200-250 new contributors every release (i.e. every 2 1/2 months). We are not starved for new contributors at the moment at…