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: <alpine.LNX.2.00.1009221520560.7689@nippy.intranet>
Date:	Wed, 22 Sep 2010 15:44:21 +1000 (EST)
From:	Finn Thain <fthain@...egraphics.com.au>
To:	"Justin P. Mattock" <justinmattock@...il.com>
cc:	Matt Turner <mattst88@...il.com>, trivial@...nel.org,
	linux-kernel@...r.kernel.org,
	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Dimitry Torokhov <dmitry.torokhov@...il.com>,
	Ben Pfaff <blp@...stanford.edu>,
	Mike Frysinger <vapier.adi@...il.com>
Subject: Re: [PATCH]Update-broken-web-addresses-in-the-kernel


On Tue, 21 Sep 2010, Justin P. Mattock wrote:

> On 09/21/2010 07:41 PM, Finn Thain wrote:
> > 
> > On Tue, 21 Sep 2010, Justin P. Mattock wrote:
> > 
> > > On 09/20/2010 10:17 PM, Finn Thain wrote:
> > > > 
> > > > I would say that if a URL is in the web archive, then no patch is
> > > > needed.
[snip]
> > Applying your reasoning that "people are still wanting to read the old
> > info", a policy to accept patches like:
> > - http://foo/bar
> > + http://web.archive.org/web/*/foo/bar
> > would imply another continual stream of patches when the domain foo
> > changes hands. Then you have to pach,
> > - http://web.archive.org/web/*/foo/bar
> > + http://web.archive.org/web/YYYYMMDDHHMMSS/foo/bar
> > 
> > Then the problem becomes what is the correct YYYYMMMDDHHMMSS? The one 
> > closest to the datestamp of submission of the patch? Or the datestamp 
> > from the email that submitted the patch? When these questions arise, 
> > it becomes a new burden on maintainers to determine the right version 
> > of the web page in the archive, and whether or not the latest version 
> > is the best one.
> > 
> 
> just was looking for apmv1.1.doc my search results are not so 
> good(everything is pointing to v2) but it is tricky to decipher..
> 
> > So both of these (arguably) continuous streams of patches would become 
> > a burden on maintainers and offer little or no benefit to those 
> > reading the source code.
> > 
> 
> true.. I see it as accommodating.. but then again maybe a museum if you 
> want to search about the first commador64 as opposed to ps3/xbox(I know 
> bad analogy, but only thing I can think of).
> 
> > The benefit to end users is also dubious, because you're chasing web 
> > pages that were abandoned, implying low value in the first place.
> > 
> 
> but at the time that was hot off the press info..(which I need to 
> respect, and should be taken care of).

I think the best solution might be to somehow ensure that, in future, new 
links inserted into the kernel are qualified with a date stamp. E.g.

  For technical information about the SUX-5000, please see:
  <http://foo/bar> (retrieved 1990/6/22)

In this way, rather than adding loads of "www.webarchive.org" boilerplate 
without solving the problem, we can push the extra workload back to the 
patch authors instead of letting it fall to maintainers.

If you know perl, you might be able to achieve this with 
scripts/checkpatch.pl.

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