public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Edgar Hucek <hostmaster@ed-soft.at>
To: jerome lacoste <jerome.lacoste@gmail.com>
Cc: Jean Delvare <khali@linux-fr.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: New Linux Development Model
Date: Sun, 06 Nov 2005 12:55:14 +0100	[thread overview]
Message-ID: <436DEF22.4010903@ed-soft.at> (raw)
In-Reply-To: <5a2cf1f60511060252t55e1a058o528700ea69826965@mail.gmail.com>

jerome lacoste wrote:

> On 11/5/05, Edgar Hucek <hostmaster@ed-soft.at> wrote:
>  
>
>> Hi.
>>
>> Sorry for not posting my Name.
>>
>> Maybe you don't understand what i wanted to say or it's my bad english.
>> The ipw2200 driver was only an example. I had also problems with, 
>> vmware,
>> unionfs...
>> What i mean ist, that kernel developers make incompatible changes to the
>> header
>> files, change structures, interfaces and so on. Which makes the kernel
>> releases
>> incompatible.
>>   
>
>
> I will ask you just one question: as a user, why did you want to
> upgrade your kernel?
>  
>
Depends on the user and what he wants to do. There are several
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.

> On a server you want stability. So you don't upgrade.

Sure, but what about securrity updates. When a new kernel release
comes out the updates are stopped for older releases. And why should
dirstribution makers always backport new security fixes ?

> On a desktop, there are probably a bunch of out of kernel modules that 
> will need
> upgrading with each new kernel modules. Just on the laptop I am using
> right now, I will have to upgrade the vmware bridge, nvidia driver,
> madwifi wireless driver, etc. And that's normal. The new development
> model didn't change that.
>  
>
 From my point of view, it makes a difference if i have to recompile
a module or realy upgrade it.

> I avoid touching my kernel on boxes I do real work with. I do build a
> new kernel for test purposes and to give feedback if there's an issue.
> But most of the time I skip 2-3 versions before finding a very
> compelling reason to upgrade. And I stick with my distribution kernel
> as much as I can.
>
>  
>
So you wanna say a new "stable" kernel isn't a realy a stable one
and i can't relay that it behaves like the older one ? If it's so, then
something is completely wrong in kernel development.

> As for kernel/drivers developers, it's another story.
>
> If it ain't broken, don't fix it.
>
> Jerome
>
>  
>

cu

ED.


  reply	other threads:[~2005-11-06 11:55 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-05  9:42 New Linux Development Model hostmaster
2005-11-05 10:29 ` Francois Romieu
2005-11-05 11:29 ` Jean Delvare
2005-11-05 13:19   ` Edgar Hucek
2005-11-05 13:44     ` Adrian Bunk
2005-11-05 13:47     ` Alistair John Strachan
2005-11-05 22:23       ` Mark Lord
2005-11-06  0:28         ` Alistair John Strachan
2005-11-05 14:34     ` Jesper Juhl
2005-11-05 14:48       ` Oliver Neukum
2005-11-05 14:56         ` Fawad Lateef
2005-11-05 15:28         ` Adrian Bunk
2005-11-06 10:52     ` jerome lacoste
2005-11-06 11:55       ` Edgar Hucek [this message]
2005-11-06 12:39         ` Adrian Bunk
2005-11-06 12:57         ` Bernd Petrovitsch
2005-11-06 17:38         ` Jean Delvare
     [not found]       ` <436DEEFC.4020301@ed-soft.at>
2005-11-06 13:43         ` jerome lacoste
2005-11-09  0:11           ` caszonyi
2005-11-09  0:23             ` Con Kolivas
2005-11-09  7:00               ` Diego Calleja
2005-11-09 12:30             ` jerome lacoste
2005-11-09 14:03               ` caszonyi
2005-11-09 15:45                 ` Marcos Marado
2005-11-06 16:50       ` John Carlson
2005-11-06 18:17     ` Bernd Petrovitsch
2005-11-09  0:16       ` caszonyi
2005-11-06 15:22 ` Jim Nance
2005-11-06 16:55   ` John Carlson
  -- strict thread matches above, loose matches on Subject: below --
2005-11-09  1:47 Ian Kumlien
2005-11-09 11:08 ` Marcos Marado
2005-11-09 11:30   ` Ian Kumlien
2005-11-09 12:03     ` Wed, 9 Nov 2005 13:03:07 +0100
2005-11-09 15:49       ` Ian Kumlien
2005-11-09 15:58         ` Al Viro
2005-11-09 16:32           ` Ian Kumlien
2005-11-09 12:37     ` Marcos Marado
2005-11-09 16:01       ` Ian Kumlien
2005-11-10  0:55         ` Alistair John Strachan
2005-11-10 15:10           ` Mark Lord
2005-11-10 19:29             ` Alistair John Strachan
2005-11-10 19:47               ` Ian Kumlien
2005-11-09 19:05   ` Bill Davidsen
2005-11-09 20:10     ` Marcos Marado
2005-11-10  0:57       ` Alistair John Strachan
2005-11-10 20:08         ` Bill Davidsen
2005-11-10 20:21           ` Alistair John Strachan
2005-11-12 13:45       ` Bill Davidsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=436DEF22.4010903@ed-soft.at \
    --to=hostmaster@ed-soft.at \
    --cc=jerome.lacoste@gmail.com \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox