lkml.org 
[lkml]   [1996]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Drawbacks of implementing undelete entirely in user space
Date
From

JD = Justin Dossey <dossey@flex.net> wrote:
JD> I suppose I cast my vote for user space. This just doesn't seem to
JD> be a system-level function, and it's definitely something that varies
JD> in importance from system to system. Oh, for those with free
JD> processor and tight disk, there's always gzip...

I agree completely. When it's about user interaction, I always like the good
examples you can find on a Mac. Try to find a delete button on a Mac GUI -
it's simply not there. Your only option is to drag files into the Trash. Now,
if you're experienced and want to try their MPW environment, you suddenly
discover that there _is_ a delete over there and it's just about as user
friendly as the Unix one :-). But for normal users, the interface simply
doesn't let the user access the Mac equivalent of unlink(), and that's
perfectly sufficient.

Now, if you have unexperienced users with Unix shell accounts, I can
understand that you'd rather have the kernel handle this problem. But I tend
to agree with Linus that kernel enhancements should be directed towards the
future (which is GUI), not for satisfying everybody who chooses to stay in the
past. A correctly designed GUI, as the Mac shows, is more than able to handle
the undelete problem all by itself with minimal OS support.

Regards

Cees
--
Cees de Groot <C.deGroot@inter.NL.net>
OpenLink Software, Inc. replies in Dutch, German, English.




\
 
 \ /
  Last update: 2005-03-22 13:37    [from the cache]
©2003-2011 Jasper Spaans