[gobolinux-users] Re: 'updatedb' to 'locate',
an idea to system scripts
hisham.hm at gmail.com
Sun Aug 28 21:21:32 GMT 2005
On 8/28/05, teike <teikecorp at yahoo.com.br> wrote:
> 1st time I tryed 'locate' it didnt work.
> I found out I had to run 'udatedb', and that it isnt a default system
> service at GoboLinux.
> So sometimes I login as root and run:
> nice -n 19 updatedb&
> But now I put it on a system task with 'kdesu kcron' just as 'updatedb'
> to run once per hour everyday.
Yes, cron and updatedb are not enabled by default. It's up to the user
to enable it if they want. In many distros, there are a lot of
services enabled on boot that the user never uses. We chose to ship
with the bare minimum, and let the user add following their necessity.
If you like locate, sure, go ahead and enable it in your system. :)
> Tho I thought that it would be interesting to be run just after an
> InstallPackage, successfull Compile, RemoveProgram... the system
> scripts, also in the downloaded files paths (if any being kept). So it
> would be automatically run just in the new directories.
> Or is used, at GoboLinux, another fast way to locate files?
I can only speak for myself, of course: I don't use locate.
Personally, I think the need for locate diminishes a lot in the
GoboLinux tree, compared to standard Linux trees. In a usual Linux
distro, a binary, library or header can be in one of many places. In
GoboLinux, we have the /System/Links tree that works like a natural
index: every binary is under /S/L/Executables, every library under
Libraries, etc. To know where exactly a program is (in other words,
which package it is a part of), I just do "l" (ls -l equivalent) to
see where does the link point to. For executables, the "which" command
is even more convenient.
Based on this idea of the /S/L tree as a "filesystem index", we have
the SystemFind script, which scans it and returns the linked files
directly. Scanning /S/L is much faster than scanning the entire
/Programs tree: there are less directories to traverse (and at least
in ReiserFS, symlinks are stored in the same inode as the directory,
making it a time and space efficient operation).
> 'find' isnt fast in the 1st time you run it, and after its cash is cleaned.
Additionally, since directories like /System/Links/Libraries and
/System/Links/Executables are accessed frequently, they are usually in
the disk cache.
ps: cool, I'll add this information in the SystemFind entry in the wiki :-D
More information about the gobolinux-users