__/ [ Mark Kent ] on Wednesday 28 June 2006 09:18 \__
> begin oe_protect.scr
> [H]omer <spam@xxxxxxx> espoused:
>> Mark Kent wrote:
>>
>>> Perhaps what could be useful would be to create a higher-layer
>>> function to combine the capabilities of locate, dpkg -S, -L, find,
>>> fuser, ps, w, netstat, man, info, /usr/share/doc, tcpdump, mount,
>>> /proc, file, so that any entity which can be displayed can be
>>> identified easily, rather like the "properties" tabs in MS Windows
>>> were intended to do, but never really did.
>>>
>>> Having re-read my para above, it's almost like a request for a
>>> special shell dedicated to identifying things. Some careful
>>> consideration about priorities and context could help to determine
>>> the most useful output to present to a user.
>>
>> That's what metadata is for; a particular function which is notably
>> extensive, and extensible in Reiser4, through the so-called "file as a
>> directory" access method. E.g.:
>>
>> #] file /home/joe/foobar
>> /home/joe/foobar: ASCII text
>> #] ls -l /home/joe/foobar
>> -rw-rw-r-- 1 joe joe 1028096 Jun 28 03:59 /home/joe/foobar
>> #] ls -i /home/joe/foobar
>> 18125757
>> #] find / -inum 18125757
>> /home/joe/foobar
>>
>> Versus
>>
>> #] ls /home/joe/foobar
>> /home/joe/foobar
>> #] cat /home/joe/foobar/size
>> 1028096
>> #] cat /home/joe/foobar/inode
>> 18125757
>> #] find / -property:inum 18125757 # fictitious example
>> /home/joe/foobar
>>
>> All that remains is the extension of current userland tools, to
>> support this extended property set, and perhaps a means by which to
>> quickly locate and manipulate files by directly referencing those new
>> attributes, such as it is with inodes now.
>>
>> Fictitious example:
>>
>> #] filestat --query COUNT $IDATA WHERE type = "ASCII text"
>> 4027 records
>> #] filestat --select "*" FROM $IDATA WHERE type = "ASCII text"
>> /home/joe/foobar
>> /home/stu/barfoo
>> /home/vil/snafu
>> etc.
>>
>
> Good example, which would make an excellent addition to the toolkit, way
> beyond what is easily done at the moment. Combined with metadata around
> sockets, and searches of text within ascii files (and perhaps others?),
> we get closer to a highly functional search capability.
Have a look at these:
http://reverendted.wordpress.com/2006/06/17/show-me-that-new-gnome-main-menu/
http://reverendted.wordpress.com/2006/06/18/customizing-the-gnome-main-menu/
(upcoming SLED 10)
> One of the major problems with searching is that it's the brain's
> problems we're trying to address, not the computer's. Even at home, I
> get very frustrated with Mrs Mark, au pair and kids all creating what I
> call "everything drawers", because things are randomly dumped in them,
> so next to impossible for /somebody else/ to find.
I refuse to accumulate paper and make much use of drawers. I intentionally
gave away all my drawers at the office, so that I simply cannot use them. I
scan papers and file them sensible on my hard-drive instead where they can
easily be found in the tree (I have about a quarter of a million files, over
5000 directories).
> If the computer can resolve the "everything drawer" problem, then we've
> made good progress.
True. This 'drawler paradigm' actually reminds me of:
http://www.youtube.com/watch?v=M0ODskdEPnQ
Best wishes,
Roy
--
Roy S. Schestowitz | Bring home the world cup, England!
http://Schestowitz.com | Free as in Free Beer ¦ PGP-Key: 0x74572E8E
Cpu(s): 20.3% user, 3.6% system, 17.6% nice, 58.5% idle
http://iuron.com - semantic engine to gather information
|
|
