Re: New Linux Development Model

[jerome lacoste <jerome.lacoste@gmail.com>]

On 11/9/05, caszonyi@rdslink.ro <caszonyi@rdslink.ro> wrote:
[...]
> >> reasons why a user wanna upgrade to new kernel. Maybe new supported
> >> hardware and so on. It's frustrating for the user, have on the one side the
> >> new hardware supported but on the other side, mybe broken support for
> >> the existing hardware.
> >
> > New kernel feature and new supported hardware would be the only reason
> > for me to upgrade. Personally that doesn't come that often. My
> > hardware configurations don't change that much. I make sure it's well
> > supported, not just recently. When one buys a non supported hardware,
> > one should know the path chosen won't be the easiest.
> >
>
> There are other reasons for using a new kernel. One of them is
> interactivity. In the days of 2.4 one could achieve decent interactivity
> for the desktop using preempt and low latency patches. For 2.6
> interactivity was a real issue (possibly because of the new development
> model).

I don't get it. You say that with 2.4 + patches you had good
interactivity and with 2.6 you don't? Why did you switch then?

> >> And why should dirstribution makers always backport new security fixes ?
> >
> > Because they want to ensure maximum stability. That's what users are
> > (sometimes) paying for.
> >
>
> Maximum stability of what ? If the distribution kernels are based on
> vanila kernel (i.e. are based on unstable kernel) how stable will they be
> ?

Maximum stability of the kernel they deliver. When you fix a
vulnerability, you fix a vulnerability. You don't just happen to add a
new bunch of features, and a new bunch of bugs. Otherwise you are
going to piss off your users a lot.

Everybody does that, including Microsoft (most of the time).

>   On lkml someone said that "stable means it won't crash very often".
> This sounds like Windows(TM)

I've had Linux running on various hardware, from Pentium I machines to
AMD 64bits machines and various laptops. The most problematic hardware
I've had to deal was a MythTV box running on a Via EPIA M motherboard
(due to what seems to be DMA issues on the board), and PCMCIA hang a
on a Dell laptop. Some installation issues on new hardware and a
wireless pcmcia card whose drivers are not stable. Apart from that,
Linux has always been running very well. I had less than 10 hangs and
hard reboots in 8 year with 20 machines. I had more oopses but 95% of
the time confined to a module and not critical. And I've had more
hardware failures, drives, disks, keyboards, pcmcia&usb ports, mice,
motherboard than kernel issues.

On the security side, I've been broken into twice, one because of a
very dumb misconfiguration on my part on a desktop (guest/guest
account, no firewall, ssh server enabled and not restricted....), one
on a server, probably because of an external php program whose
security was not handled by the distribution (haven't investigated the
issue yet, server is down).

To me, the most problematic crashes on desktops are X failures,
because I lose several minutes to set up my desktop again.

And firefox crashes (or becomes unusable) way too often (around twice a week).

> > And second 90% of the security issues will not affect the majority of
> > the home users (because they are restricted to a particular area of
> > the kernel not affecting the user, or because they already require
> > access on the machine to be exploitable). You will have much more
> > risks using a box with an unpatched php or apache than with an
> > unpached kernel, or without a proper firewall configuration.
> >
>
> Some holes are remote ;-)

That's your 10% (probably even much lower than that). And if you have
a firewall on your desktop, most services turned down, and are behind
a private network with a router with its own firewall, the probability
that you get a remote attack on your particular version of the kernel,
for which they are very few exploits in the wild anyway, is much lower
than having a hard drive failure or a X server crash because of a
driver issue.

If you care about stability, don't touch what works.

J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/