On Jan 23, 2008 11:08 PM, Greg KH <[EMAIL PROTECTED]> wrote:

> In the end, the development time for a driver developer for Linux is
> less than that of other operating systems as the maintaince is done for
> them for all future versions, and the ammount of code they have to write
> in the first place is smaller.

API tweaking might be done for you automatically, but
certainly _not_ maintenance or testing. Or don't tell me
you have every piece of hardware supported by Linux
available and that you  actually do test if you broke
them :)

So most certainly maintenance is not done. And actually,
most of the testing effort done against the original driver
was just rendered useless with the API tweak.


> > > This also provides a more secure, and better product for the user in the
> > > end.  They never need to worry about external drivers, and everything
> > > "just works" for them automatically.
> >
> > As I told you before, this is a nice idea but 'in real life'
> > it's load of bollocks :). If we don't make it possible for
> > users to install 'out-of-tree' drivers (and just drivers,
> > nothing else) they are forced to do major kernel update
> > after each new gadget bought. And that, in real life terms,
> > means totally new OS to install. Plug and play, you say?
>
> No, not at all.  You should be able to drop in a new kernel just fine,
> with only minor package updates at times.

Joe Random Hacker can, regular user can't.

That, and I don't think SUSE would be too happy supporting
2.6.23.14 for SLED10 either. Andreas, would you be happy
with it :) ?


> As proof that this works, I was just talking with a very large company
> that relies on Linux last week.  They use RHEL 3 on almost all of their
> systems.   But as RHEL 3 is 2.4 based, and doesn't support a lot of new
> hardware, and has lots of other issues, they just drop in the latest
> 2.6 kernel on their own, and their developers never even notice the
> difference, except that their machines work better.
>
> So, in the "real life" it isn't a load of bollocks, sorry :)

OK, try asking your auntie to do the same thing ;)

Yeah, it's a piece of software. Given enough time and
money anything can be done for it. But whether or not
it's feasible is another thing.


> > IMHO the whole concept of providing complete kernel in one
> > huge blob is flawed. Optimal case would be to break it into
> > pieces with no dependencies.
>
> I'd be interested in seeing your patches to attempt such a thing.

With current design this would probably be impossible :/


-- 
// Janne
-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to