>> 2. Why in the kernel?
> Why does the kernel necessarily help?
The problem of userspace realizations is that
a. thay can not store resources together with data.
b. thay must index files by full names.
Only the kernel has direct access to the disk.
I.e. libraries use *COMPLETELY* DIFFERENT ALGORITHMS.
(See the example below.)
>> a. *Huge* perfomance losses (10 - 1000%)
> This point is not defended very well:
See the example below.
>> For example to determine type of all files in a directory
>> file managers must:
>[...]
>> - refer to /etc/magic (very slow)
> How? Why? I'm curious. Is it the repeated interpretation of objects?
> Is user->hardware->user interaction?
No, user->hardware->user is just a trifle.
(example <-- )
- scanning /etc/magic for 1000 files in directory is *seconds*.
- parsing extensions (DOS sort of metadata) is milliseconds.
- following @albod/type is microseconds.
>> - create cache database (it will duplicate file names
>> => waste disk space)
> Hmm I already give 128MB to my swapspace.
> Why not not use a little of that?
To give 50 Mb for 'file types' cache only???
IMHO it's much uglier than fixing findutils.
>> b. Security holes
>> ACLs in tarball?
> This is a good point. However, it may be solvable with a much simpler
> kernel mechanism.
a. What is simpler: one powerful mechanism or 100 simple mechanisms?
b. What simpler kernel mechanism?
If you store somewhere additional data - you must rewrite mv, aren't you?
> I honestly can't believe that this is going on for so long. I don't
> think applications are already too slow. What applications?
Personally I am not satisfied with file managers perfomance.
'DOS Navigator' is 1000 times faster than kfm determines file types.
(DOS uses file extensions)
> I don't see any problems with the current way of doing things.
You are lucky! But some of us use sluggish file managers, etc. :-(
> parsing conf files is slow? Where'd anybody get that idea from.
I did not benchmarks: I only yawned and listened to the HDD.
> How often do you parse conf files?
a. Initialization of * program.
For comparison: BeOS starts (with full GUI) in 6 seconds.
b. loading xpms.
c. logging dynamic data.
Best regards.
Alexander.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/