[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46A7074B.50608@gmail.com>
Date: Wed, 25 Jul 2007 10:18:19 +0200
From: Rene Herman <rene.herman@...il.com>
To: Valdis.Kletnieks@...edu
CC: david@...g.hm, Nick Piggin <nickpiggin@...oo.com.au>,
Ray Lee <ray-lk@...rabbit.org>,
Jesper Juhl <jesper.juhl@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
ck list <ck@....kolivas.org>, Ingo Molnar <mingo@...e.hu>,
Paul Jackson <pj@....com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: -mm merge plans for 2.6.23
On 07/25/2007 09:14 AM, Valdis.Kletnieks@...edu wrote:
> On Wed, 25 Jul 2007 07:30:37 +0200, Rene Herman said:
>
>> Yes, but what's locate's usage scenario? I've never, ever wanted to use
>> it. When do you know the name of something but not where it's located,
>> other than situations which "which" wouldn't cover and after just
>> having installed/unpacked something meaning locate doesn't know about
>> it yet either?
>
> My favorite use - with 5 Fedora kernels and as many -mm kernels on my
> laptop, doing a 'locate moby' finds all the moby.c and moby.o and moby.ko
> for the various releases.
Supposing you know the path in one tree, you know the path in all of them,
right? :-?
> You want hard numbers? Here you go - 'locate' versus 'find'
These are ofcourse not necesary. If you discount the time updatedb itself
takes it's utterly obvious that _if_ you use it, it's going to be wildly
faster than find.
Regardless, I'll stand by "[by disabling updatedb] the problem will for a
large part be solved" as I expect approximately 94.372 percent of Linux
desktop users couldn't care less about locate.
Rene.
-
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