gregkh

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 way that actually means anything viable.

If you just want to count users, then that would only be Android (everything else is a rounding error.) After Android, that would be Yocto, and then Debian. All distros after that are mere fractions of overall users compared to those 3 by number of running systems alone.

If you want to count it as "$ spent on Linux" then that cuts out Android and Yocto and Debian as those distros are free, and would focus purely on the tiny installed base of paid Linux systems, and cut everyone else out.

So what is a fair way to do this other than "we notify no one, and tell everyone to always update their systems to the latest stable releases that we support."

Especially as there is no way for us to determine your use case (i.e. if a specific bug is a vulnerability for you or not.)

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 obvious as to what you are doing.

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 companies want to host) does not mean that somehow less is being given to the kernel community at all. It is not a zero-sum game here at all, that's not how the LF works in any way.

Again, this would have been easy to verify if someone just asked us.

So to repeat, no "abandonment" is happening here at all, the opposite is happening, just like it has for the entirety of the LF's existence, support has grown every year.

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 such a click-bait headline "LTS kernels are no longer supported for 6 years because it turns out no one used them." doesn't have that same fun sound...

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 kernel code, but as of right now, none have been merged.

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 their developers be a valued part of the overall kernel community is a very good thing to support.

Corporate guys "manage me"? Have you talked to any corporate guys who have actually tried that and discussed the results with them? :)

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 point in time, I did not have long hair anymore (cut it off when I turned 30 which was before OSDL was ever started.)

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 :)

Also, udevd is a program, not a library.

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 systemd codebase in order for lots of duplicated code and functionality to be removed.

By doing this, we have made the maintenance and support for this core userspace tool much easier for everyone who was involved in working on it.

If the developers involved in a project do not do what you want with that project, feel free to fork the project as that's the beauty of open source! And hey, that's exactly what the eudev developers did, go use their fork if you want to, no one is forcing you to use the version from systemd, just like no one is forcing you to use any other open source program. It's your choice to do so or not :)

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 problems, better development cycle as feedback can be more specific, easier evolution of changes, etc.)

I wrote a whole chapter in the book "Beautiful Code" about how this development model can help create an end result that is almost always better than the initial "huge" submission model. Check it out if you are interested, it should be free online somewhere...

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 development, and is one reason why breaking changes up into tiny pieces is so powerful. We can take the pieces that make sense now, and allow the developer to redo the portions that are not ready yet, instead of having to reject the whole thing if it were done in one single "chunk."

Also note that the TTY/serial portions of this hardware support was already merged through the serial tree because they were independent and didn't affect anyone else.