Re: [Gnu-arch-users] Re: Linus

[Tom Lord]

    > From: Colin Walters <address@hidden>

    > On Mon, 2003-10-13 at 01:36, Tom Lord wrote:
    > >     > I haven't personally, but I have known and worked with people who 
do
    > >     > (here at the Ohio State University), and I am quite positive that 
they
    > >     > would just laugh in my face if I told them that this new revision
    > >     > control system I wanted them to use would require the users to 
have new
    > >     > accounts for each project.  

    > > For the N+1th time, their are plenty 'o solutions which don't require
    > > new accounts (not that new accounts should be that big of a deal).
    > > This has been pointed out to you so many times by now that it is
    > > patently, obviously, horribly, irresponsible (if not dishonest) for
    > > you to argue points otherwise.

    > You conveniently cut out the part where I say that they would also
    > likely be averse to maintaining some sort of hacked up ssh subsystem.

My mistake.

    > And what are these other "plenty 'o solutions" of which you speak?

To name one that seems particularly relevant to the specific situation
you are describing:

I have previously offered to allow you to configure what program the
pfs-sftp.c code invokes (where `ssh' is currently invoked) based on
the URI of the archive location.

I gather that on this system with highly restrictive admin policies
you nevertheless have a shell account, right?   Therefore, why not,
instead of invoking the sftp subsystem directly, write a client-side
program that invokes ssh and sends some commands that adjust your
umask and exec an sftp server?

(A fairly minor variation on that solution applies in the case that
you don't have a shell account.)



    > > So cut it out.  Don't be that kind of loser, please.

    > What's up with the ad hominems?  I thought you'd be better than
    > that. 

Please don't take it that way.  

I'm just mirroring in reality what you merely anticipate your
sysadmins will do.  If you think that its reasoanble that they will
_laugh_in_your_face_ if you take them a problem you're having with
their system, and a proposed solution (that they might reject in favor
of finding a better solution), then you must also think it's
reasonable if I poke at you by asking you not to be a loser.  Heck, I
even said "please".

You're between a rock and a hard place here:

rock: sysadmins of an important machine who have some established
      practices 
hard place: a valuable project that is being carefully engineered


Which of those "weighs more" in your mind?  Both have legitimate
interests and, at a quick glance, you decided they were in conflict.
(The solution suggested above may make the conflict disappear,
though.)

Who is to be master?  In _mere_anticipation_ of the admins refusing to
help you (and even laughing in your face) you're proposing to
compromise the engineering of arch.  Sorry -- I'm not buying it.

So if you're going to argue to me that you can't do this or that
because sysadmins will "laugh in your face", and I _know_ that help
from the admins on this issue will:

        *) Cost them almost no work
        *) Not compromise anything at all assuming their practices
           are just minimally sane

then I'm going to reply in kind:  they'll laugh in your face?  ok,
i'll call you a loser.   _You_ called this tune -- I'm just singing
the harmony.

Mostly I think you should just get over it.  Don't _assume_ that you
have no opportunity to make reasonable requests of the admins (though
you probably don't need to make any in this case).  Heck, as far as
I'm concerned -- if they're managing a 3k user environment?  Extra
accounts (not necessarily fully general user accounts, but extra uids)
should be available like candy.  Why?  Because they're a damn useful,
safe, and manageable tool and by withholding that tool they're making
the system distinctly less useful to the users they're supposed to be
supporting.

In any event: at your site, the ssh wrapper proposed above should
solve the umask problem -- without any extra accounts, ssh subsystem
hacking, or anything.

-t