Michael O'Keefe wrote:
The larger problem is that we shouldn't be using a "filename".
Hans Reiser (of Namesys) would agree with you.
What are the proposed alternatives ?
Queries primarily.
I have no objection to keeping a filename.
However, I note that I type the following idiom:
find . -type f -exec grep <someregex> {} /dev/null \;
DOZENS of times *every day* (yes, I have an alias for it). I rarely use
"locate" or its ilk unless I'm hunting down library linkage errors
(*how* many places does pkg-config exist on my system?)
I want the ability to search files. *FAST*. And I want the index built
without turning my computer into a dog while doing it (yes, I'm talking
about Spotlight).
The big problem right now is that heavy disk access grinds most consumer
systems to a halt. In fact, I would argue that heavy anything grinds
most consumer grade systems to a halt.
It's ironic given that Linux/BSD/et al. are held up as examples of
monolithic kernels being superior to microkernels, but I think that
we're finally about to make a shift to microkernels. Too many things
are starting to make real-time demands that computers can't service.
Both Vista and OS X did *major* surgery on their kernels in order to
cope with the demands of video playback.
I think that we're about to see a good, real-time microkernel (not Mach,
yeccch) emerge for general use. I would expect that it will be
something like L4: http://os.inf.tu-dresden.de/L4/
which will replace the underlying monolithic Linux kernel but leave
everything else in place.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
