lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 15 Feb 2008 14:07:41 -0500
From:	Bill Davidsen <davidsen@....com>
To:	Adrian Bunk <bunk@...nel.org>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Driver removals

Adrian Bunk wrote:
> On Wed, Feb 13, 2008 at 09:26:26PM -0500, Bill Davidsen wrote:
>> ...
>> In general, if a driver works and is being used, until it *needs*  
>> attention I see no reason to replace it. I don't agree that "it forces  
>> people to try the new driver" is a valid reason, being unmaintained is  
>> only a problem if it needs maintenance. I am not going to reopen that  
>> topic, I'm simply noting a general opposition to unfunded mandates, and  
>> requiring changes to kernel, module and/or rc.local config is just that.
> 
> Keeping a working unmaintained driver in the tree is not a big deal - we 
> have hundreds of them.
> 
> But you miss the main point that removal of an obsolete driver with a 
> new replacement driver forces people to finally report their problems 
> with the new driver, thus making the new driver better.
> 
You sure are proud of that new driver! People won't use it because the 
old one is working fine, so you think it's fine to force them to make 
changes in their system to use the new driver. Best case is it works 
after costing the user some time, worst case it doesn't and breaks their 
system, so they stop upgrading the kernel and don't get security fixes.

> After all, the people who scream loudly that the new driver doesn't work 
> for them when the old driver gets removed are the people who should have 
> reported their problems with the new driver many years ago...
> 
Is it not obvious that the problem lies with the "when the old driver 
gets removed" part, there is absolutely no effort needed to keep an old 
driver, and if it's left in until some change requires rewriting every 
module in the kernel, it's likely that either the old hardware or the 
user will die before that ever happens again.

There is no benefit to users, if the old driver didn't work they would 
have switched, there's no saving in support effort because, as you 
pointed out, there are "hundreds of them" now.

This reminds me of Microsoft and XP vs. VISTA. MSFT is stopping sales 
and support of XP to "force people to upgrade" to VISTA. You want to 
"force people to upgrade" to newer drivers. The difference is that MSFT 
at least has money as a reason, as far as I can tell the reason you want 
to force people to use new drivers is because people put all the effort 
into writing the new drivers and now most of us want to use the old one 
if it works. We don't want to change configuration and hope something 
else new works, because we know the old driver works for us and we want 
to use our system instead of helping test the new driver.

I appreciate the effort it took to write new drivers, I believe most 
users able to build their own kernels do. I use new drivers on new 
systems because install picks them and a new system has to go through 
shakedown in any case. I just wish that *you* could appreciate that a 
driver change requires user effort and chance to find bugs in a new 
driver, for each and every system, many of which are at EOL now. I wish 
you valued the user's time as much as users value developer time.

*EOL - end-of-life, if your organization doesn't use the term. the "it's 
paid for, use it but don't spend money on it" phase of ownership.


-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ