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]
Message-ID: <20080216073907.GT8953@1wt.eu>
Date:	Sat, 16 Feb 2008 08:39:08 +0100
From:	Willy Tarreau <w@....eu>
To:	Valdis.Kletnieks@...edu
Cc:	Bill Davidsen <davidsen@....com>, Adrian Bunk <bunk@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Driver removals

On Fri, Feb 15, 2008 at 08:52:27PM -0500, Valdis.Kletnieks@...edu wrote:
> On Fri, 15 Feb 2008 20:08:13 EST, Bill Davidsen said:
> 
> > can never make you see why technological extortion is evil. People have 
> > always moved to new drivers without pushing because they were *better*, 
> > guess that model is dead.
> 
> And the drivers get better because the Code Fairy comes and sprinkles magic
> bugfix dust all over them? And the Code Fairy knows where to sprinkle bugfix
> dust because it can see where the Bugreport Fairy sprinkled Bugreport Dust?
> 
> Yes, people will move without pushing when the drivers are better.  However,
> remember that a major cultural motivation for the GPL is the concept of "give
> back".  And if a user can't be bothered to even give back enough to say
> "wow, this blows, my Frobnozz9800 doesn't work with this driver", that's a
> problem with the user.

I don't understand why kernel developers always think that users spend
their whole time testing their new stuff. That is mostly true for a lot
of desktop users, but definitely not for servers. On a server, you may
*ignore* that a new driver exists for years. The basic make oldconfig
does the stuff right.

An old driver must spend some time marked "deprecated", if possible with
the config option changed so that at least *something* informs the admin
that it may soon be removed. It looks like this is something that people
building a kernel every day and never getting more than one week of uptime
do not understand. But there are many people who build once a year and
upgrade that often at most, unless there is a big security issue.

If the old driver simply keeps silently building when marked deprecated,
noone will notice. And as Bill pointed it out, we should also make sure
that when marked deprecated, the old one always refers to the new one so
that the guy noticing this during the build has time to set up a test
machine to try that new driver.

Not everyone has a mouse and a joystick attached to the computers he
builds kernels for...

Willy

--
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