| Using an very old and unsupported kernel is completely normal for embedded consumer devices like home routers.
Normally the kernel is chosen by the SoC vendor when they start the new SoC project. Updating to a new major kernel version takes multiple man years of work because of all the vendor patches hacked into the kernel. Probably 500k to 2M lines of kernel code for such a router. After such an update you also have to run all your validation again which also takes effort. Normally there are 4 years between the start of a new SoC project and the first device with this SoC hitting the consumer market. Then this SoC is used for new projects the next 4 years and shipped in new products an additional 4 years. Now the kernel is 12 years old. ;-) Even when an SoC vendor provides a new SDK with a more recent kernel, most of the device manufacturers like Netgear would not upgrade existing products to this new SDK with the new kernel. They also have extensions to the kernel and would have to adapt them and then do an extensive validation again. Normally even security updates are only taken if someone proves that this specific devices is affected. Often board manufacturers do not even want to use the new SDK with the new kernel and security updates for new products when they already have devices with the old SDK, because this would reduce their possibility for reuse. The SoC vendor wants to reduce effort and will avoid to supporting many different kernel versions. If the major customers do not want to upgrade to a more recent kernel version they will stay at something old because the board manufacturers want to. The problem is that the customer does not care for security. The customer cares for security features you can print on a box, but not for something like fixing publicly known bugs in the kernel in 6 months. The home router industry is a hardware business, it is run by hardware experts and they run software like hardware. You start a project, build the system (hardware + software)), you validate the features and then ship it. Now you can start the next project. If you want to change this you have to request this directly, for small customers this is no really useful, but if you are an ISP and buy 500k units a year, then you can put some peruse on the supply chain. Please communicate your requirements often and to many people in your supply chain and not as one of the 5000 requirements in the excel sheet. If you decide against a vendor because of their software, communicate this to them directly and to many people in his organization, to increase the likelihood that it reaches someone who understand this and fixes it in the future. If they improve you can choose between more vendors next time. |
What factor of man years do you imagine OS vendors put into release engineering ? Some open source vendors support multiple streams of the same kernel across multiple architectures all at the same time for over 10 years. The problem is not impossible, not even hard, just work.
> Probably 500k to 2M lines of kernel code for such a router.
What functionality do they include that is not included in standard Linux ? I have setup a router that does the same as these systems with little work. No fancy GUI though.
I _guess_ they could not upstream their kernels ./arch. However the arch specific code doesn't churn hard between major releases.
Do you think you're overselling the complexity they have to manage ?
> The home router industry is a hardware business, it is run by hardware experts and they run software like hardware.
I think this is the crux of the discussion, they simply do not consider software updates as part of the life cycle, until they get customer demand they will not.