On Tue, Jan 25, 2011 at 10:55 PM, Always Learning <centos@g7.u22.net> wrote:
>
> On Tue, 2011-01-25 at 14:25 -0800, Benjamin Smith wrote:
>
>> On Tuesday, January 25, 2011 11:20:34 am Always Learning wrote:
>> > Then one day a big bad wolf called Oracle of very expensive Oracle SQL
>> > fame swallowed Red Hat, like they swallowed MySQL, Solaris, Open Office
>> > and Visual Box. *The long term future for these is uncertain.
>>
>> Whaaa...? Facts would seem otherwise.... Here's an article from just a few
>> months ago!
>>
>> http://www.glgroup.com/News/Oracle-to-Red-Hat--Its-Not-Your-Fathers-Linux-
>> Market-Anymore-51058.html
>
> Thank you. Happily I got the 'swallowed Red Hat' wrong. Sadly the long
> term future for Red Hat, MySQL, Open Office and Visual Box is certainly
> uncertain.
>
> I've seen the changes in the computer world first-hand for 43 years
> staring when there were no screens, no keyboards and no disks although
> one installation, a KDF9, did have a magnetic drum. Everything changes.
> Computer companies and software change, evolve and then eventually
> disappear. It's 'computer evolution'.
[...]
> Paul.
> England,
> EU.

Why does Redhat keep getting thrown into the mix with MySQL, OO.org
etc...? It's already been said here that Oracle did not buy and
doesn't own anything related to Redhat. Oracle may have relaunched a
competitor to Redhat Linux (they had to relaunch because, frankly, no
one was using OHEL), but that's not the same at all as the situation
with MySQL, OpenOffice, etc... They just don't belong in the same
sentence.

Oracle now owns Sun, which is the company that sponsored and ran those
other projects. Oracle is now actively dismantling many of them.
They've already killed a bunch, and the ones that seemed like they
might be around for a while now also look somewhat shaky.

Nothing is certain in any market, but Redhat is the 900lb gorilla in
the Linux market, while Oracle has yet to make any significant inroads
as an OS vendor.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On Thu, Jan 27, 2011 at 2:56 AM, John Hodrien <J.H.Hodrien@leeds.ac.uk> wrote:
> On Thu, 27 Jan 2011, Always Learning wrote:
>
>> Thanks for the explanation. Now I know why locate never usually worked
>> for me - it hadn't updated.
>>
>> find is fast, especially when I restrict the search paths.
>
> But locate is faster still, in all but the smallest of cases. *I'd only tend
> to use find if I had reason to think that changes had made the locate database
> invalid. *locate with a regexp is plain good and fast.

Yeah, way back in yesteryear under UNIX, the "find" and the "locate"
tools were part of one package. Under RHEL/CentOS, locate is in the
"mlocate" package, and some folks making stripped servers rip it out
to avoid storing the database. (Think embedded OS's and NFS hosted /
and /var partitions.)

One *does* have to remember the "mlocate" package's limitations. It
doesn't browse network mounted directories, it doesn't browse /tmp or
look for other excluded targets, and it runs with the nightly cron
jobs. So if you're looking for files in /var/tmp/ or an NFS share, or
files that were created an hour ago, well, it's back to "find".

I have found it very useful, when checking updates on a machine, to
become root and run the "updatedb" command to get the mlocate database
updated.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Nico Kadel-Garcia wrote:
<snip>
> One *does* have to remember the "mlocate" package's limitations. It
> doesn't browse network mounted directories, it doesn't browse /tmp or
> look for other excluded targets, and it runs with the nightly cron
> jobs. So if you're looking for files in /var/tmp/ or an NFS share, or
> files that were created an hour ago, well, it's back to "find".
<snip>

It's not too hard to create auxilliary db's that index specific
directory trees, and to search them when you want eg, just recipies
from /home/food/recipies:

#! /bin/bash
export DBNAME="/usr/local/food/.locatedb"
/bin/mv -v ${DBNAME} ${DBNAME}~
/usr/bin/updatedb --output=$DBNAME --prunepaths='/usr/local/food/recipies/failed-experiments'

or something like that.

Then,

$ locate --database=/usr/local/food/.locatedb -i vanilla

Even better, in .bashrc add:

alias drool=locate --database=/usr/local/food/.locatedb -i "

Then,

$ drool vanilla

--
Charles Polisher

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

updatedb is not a daemon or package. It's run by cron automatically in the
night once you install slocate.

Kai


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Always Learning wrote on Fri, 28 Jan 2011 16:18:26 +0000:

> Appears not to have been installed. No trace of anything in /var/lib
> either.

It's not clear what you want to express. If you didn't install mlocate
there will be no locate or updatedb, of course.

Kai


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On Fri, Jan 28, 2011 at 11:31 AM, Kai Schaetzl <maillists@conactive.com> wrote:
> updatedb is not a daemon or package. It's run by cron automatically in the
> night once you install slocate.
>
> Kai

In CentOS 5.x, and RHEL 5.x, it's in the "mlocate" package.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos