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

[Tom Lord]

    > From: Colin Walters <address@hidden>

    > On Mon, 2003-10-13 at 00:16, Tom Lord wrote:

    > > The admin policies on savannah are an apparent problem at the moment.

    > > I believe there is a high probability that I can help fix those admin
    > > policies, if you'll give me a chance.

    > You can ask, but even if they do it I suspect they will be very unhappy.
    > And that's just one site.  Have you ever administered a large Unix site
    > (say over 3000 users), Tom?

Dude, no, but:

You're f'n right I've been around.   I cut my professional teeth as a
winy little junior member of one of the IT teams that built one of the
first serious 10K user campus networks and grew from there.   You
seriously, seriously do not impress me with that kind of rhetoric and
I disrespect the attempt.



    > 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.  


Perhaps you are mistaking correlation with causation.   You seem to be
conflating two issues:

        a) what it takes to make arch good
        b) what it takes to have standing with OSU admins

That's a question of "why we do engineering".   See below.


    > All that we need to do, minimally, is implement the permissions-copying
    > thing, 

And to do so is horrible, horrible design for many reasons that you
_should_ (judging by you level of competence evidenced elsewhere) be
able to figure out.

Let me leave you with this and hope (reasonably I think) that you are
good at working out analogies:


    > Date: Sun, 12 Oct 2003 22:01:37 -0400
    > From: Keith Moore <address@hidden>
    > Cc: address@hidden, address@hidden
    > Content-Type: text/plain; charset=US-ASCII
    > X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu
    > Sender: address@hidden
    > Precedence: bulk
    > X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
    >   mail.42inc.com
    > X-Spam-DCC: : 
    > X-Spam-Status: No, hits=-4.9 required=4.9 tests=AWL,BAYES_00 
autolearn=ham 
    >   version=2.60
    > X-UIDL: beece18eab813d102f9681231eb07392
    > 
    > > >there is no perfect foresight.  there is no perfect hindsight either.
    > > >nor is the market either efficient or reliable at choosing good 
solutions.
    > > >
    > > It appears the word "market" is overloaded with lots of 
social/political 
    > > ideology so rather than go down that road, let me redirect the point by 
    > > simply observing that running code allows the designer(s) to get 
    > > feedback about a design and its implementation implications, which is 
    > > the point about "letting the market decide". 
    > 
    > Within IETF, "running code" has usually meant interoperability tests of
    > multiple implementations of a single protocol.  These days we find we need
    > to be more concerned about the interaction between protocols than we used 
to
    > be.  The notion that protocols can be examined in isolation no longer 
holds. 
    > So for instance: we expect non-TCP-based protocols to share bandwidth 
fairly
    > with TCP-based protocols; and we expect all protocols to be reasonably 
secure
    > because when even a single protocol is compromised it can disrupt 
operation of
    > the network, other protocols, and hosts that weren't directly compromised.
    > 
    > The "market" is not in a good position to evaluate these characteristics
    > because many of these effects do not become visible to the "market" until
    > the "market" has already substantially invested in a particular path.
    > Indeed, the very discipline of "engineering" exists to minimize such
    > catastrophes. If you make design decisions based on guesswork, that's
    > guesswork; if you make design decisions based on analysis of how well a
    > solution meets well-defined criteria, that's engineering.
    > 
    > These days, a lot of people seem to be arguing that IETF shouldn't do
    > engineering.


Be an engineer -- not a self-enforced member of an underclass.

Let's fix Xouvert first, Ohio State later.   If you need some lame-ass
patch for Ohio State today, that's fine -- but don't burble on this
list as if you are pointing to something fundamental: you're pointing,
at most, to an Ohio State bug that you're struggling to work around in
a way that you ought to admit, in all honesty, is crappy engineering.

Do you have a work-study grant?   Are you working for some branch of
the organization at Ohio State whose policies are in play here?
That'd be a decent place to start.

-t