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    [W:0.018 / U:0.252 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site