Computer Old Farts Forum
 help / color / mirror / Atom feed
From: Dan Cross <crossd@gmail.com>
To: John Cowan <cowan@ccil.org>
Cc: coff@tuhs.org
Subject: [COFF] Re: [TUHS] Re: Be there a "remote diff" utility?
Date: Thu, 16 May 2024 10:49:00 -0400	[thread overview]
Message-ID: <CAEoi9W6vDK4jg7K_565siW8gZf+aLtQ_v8BfY56J=cs6Xt_rWg@mail.gmail.com> (raw)
In-Reply-To: <CAD2gp_QFmLi0aWJyzhCrFKaMLeieHT7AOjomuHu3LEhGtY60LQ@mail.gmail.com>

On Thu, May 16, 2024 at 10:44 AM John Cowan <cowan@ccil.org> wrote:
> NFS v4 provides idmapping between client uids/gids and their server equivalents using a config file.

NFS v4 came much later, of course. But even earlier NFS
implementations provided something like this, and UID 0 has been
mapped to "nobody" for many decades. But that's not terribly relevant;
the point is that, by default, the NFS protocol relies on UIDs having
meaning, as opposed to properly authenticated principles independent
of the underlying implementation of "identity", as in e.g. AFS. To be
fair, it's my understanding that NFSv4 _does_ improve on the situation
here.

        - Dan C.


> On Thu, May 16, 2024 at 9:46 AM Dan Cross <crossd@gmail.com> wrote:
>>
>> On Thu, May 16, 2024 at 7:51 AM John Cowan <cowan@ccil.org> wrote:
>> > [snip]
>> > This appears to be a VHS vs. Betamax battle: NFS was not transparent, but Sun had far more marketing clout.  However, the Manchester Connection required a single uid space (as far as I can tell), which may also have been a (perceived) institutional barrier.
>>
>> So did NFS, for that matter.
>>
>> This is one of those areas where Unix appears creaky in comparison to
>> Plan 9. `ssh` is all about remote access to resources, whereas plan 9
>> was all about resource sharing: you'd set up a namespace with all of
>> the resources (exposed as files from wherever they ultimately came
>> from) you cared about, and then operate on those "locally"; the
>> resources were shared with you and access was transparent, via a
>> consistent, file-based interface. You want to `diff` two remote files?
>> Import the filesystems they're both on, mount those somewhere, and
>> `diff /n/host1/file /n/host2/file`.
>>
>> I think the `sshfs`+FUSE model that Doug mentioned is about the
>> closest you're going to get these days.
>>
>>         - Dan C.
>>
>>
>>         - Dan C.

      reply	other threads:[~2024-05-16 14:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.BSF.2.21.9999.2405161623130.15285@aneurin.horsfall.org>
     [not found] ` <202405160651.44G6pi8G018059@freefriends.org>
     [not found]   ` <20240516073351.267351FAE3@orac.inputplus.co.uk>
2024-05-16 11:51     ` John Cowan
2024-05-16 13:45       ` Dan Cross
2024-05-16 14:03         ` Larry McVoy
2024-05-16 14:43         ` John Cowan
2024-05-16 14:49           ` Dan Cross [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEoi9W6vDK4jg7K_565siW8gZf+aLtQ_v8BfY56J=cs6Xt_rWg@mail.gmail.com' \
    --to=crossd@gmail.com \
    --cc=coff@tuhs.org \
    --cc=cowan@ccil.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).