Long-term support and backport risk [LWN.net]

Long-term support and backport risk

Posted Jun 20, 2007 19:58 UTC (Wed) by edschofield (subscriber, #39993)
Parent article: Long-term support and backport risk

This is an interesting article about an important topic. If enterprise distributors are breaking interfaces for external drivers despite their backporting efforts, Greg's third option seems an entirely sensible proposal. The solution to the problem of regressions in newer kernels is obvious: with all the time distributors' kernel teams save in not backporting features and drivers, they can do more testing and fixing of bugs in current kernels. An effective solution to the problem of proprietary drivers is to warn customers away from such hardware in favour of "certified" open hardware, by explicitly exempting uncertified and closed hardware from guarantees of stability between service-pack updates. As side-effects, the quality of mainline kernels improves for everybody and the costs of closed hardware are transferred to the vendors responsible in the form of lost sales.

(Log in to post comments)

Long-term support and backport risk

Posted Jun 22, 2007 15:47 UTC (Fri) by garloff (subscriber, #319) [Link]

> The solution to the problem of regressions in newer kernels is obvious:
[...]

For enterprise customers, it's often much better to see only 5 out of 10
old bugs fixed rather than all of them but at the cost of introducing 1
new one. They need predictability, and any regression or just the risk
of it is much more painful than not having some limitations/bugs
fixed.
This is what makes the value proposition of enterprise linux work today.
Limited change that can be assessed.

It's pretty tough to avoid this occasional bug or the risk of it:
The process to assure with a high enough level of confidence that
there's no regression anywhere would require a really large effort.
The least thing a customer wants is to test every vendor update
extensively before deploying it. What would he be paying the vendor
for?

Getting every bug out still would not be enough ...
As ballombe correctly pointed out, stability has two dimensions:
1. Get the bugs out
2. Don't change anything that a user or an app could possibly depend on

Some people argue that the kernel is not keeping interfaces stable
enough. There may be examples where I would agree, but I don't think
that criticism is fair at large.
With the speed that innovation happens in the kernel community, the
stability of anything userspace can see and expect to be stable is
quite OK.

But that's not good enough:
- Sometimes, we have not been clear enough of what we consider a stable
interface and what not. Sometimes, to get to some information, an app
actually has no choice but using unstable interfaces. sysfs is the
primary example for this.
- Sometimes, apps are horribly broken by making certain assumptions which
only happen to be true and noone sane would consider a change there to
break an interface. Yet the application breaks.

And whenever we hear about such breakage we try to help the app creator
to fix, but assuming that we can get the app world 100% clean is just
too optimistic, I'm afraid. An OS vendor also will never (and should
not need to) know about 100% of the apps that customers are running.

So my guess is that the model won't change anytime soon.

Maybe it could be changed for a subset of use scenarios, where you work
with white lists of what has been validated ...