Re: Why make the "virtual" directory world executable?

From: Matt England (no email)
Date: Wed Jun 01 2005 - 08:10:15 EDT

  • Next message: /dev/rob0: "Re: Name service error for name=yahoo.com"

    Thanks for continuing this point Keith. I'm interested in this
    "documentation for many different uses of a general application" dynamic
    for many purposes beyond just postfix...so I might get a little theoretical
    here with postfix as a case study, in hopes this does not aggravate anyone
    on the list.

    At 6/1/2005 12:08 AM, Keith Matthews wrote:
    >On Tue, 31 May 2005 23:19:31 -0500
    >Part of the problem is that postfix is not always set up to work with
    >courier, or MySQL. Different sites have different needs that must be
    >addressed differently.

    Its it reasonable to have these different needs/scenarios/usages addresses
    with different articles/topics within one content sources, while still
    gathered under one "policied" (by a general user-list community like this
    one) umbrella?

    >There is also the standard FLOSS problem of individual's preferred
    >solutions (and anyone who doesn't think that is a problem just go to any
    >Linux newsgroup and ask 'should I use Emacs or vi' or 'which is the best
    >filesystem type') and many of those preferences are based on emotion
    >rather than cold logic and will be expressed in absolute terms.

    Yes, very well understood and experienced.

    > > So why not leverage the power of a wiki in one site?
    > >
    >
    >One of the lessons I have learned in 32 years in the business is that
    >there is rarely just *one* right answer. Typically there are a number
    >that are clearly wrong (like the permissions you and Victor were
    >discussing), and there are a number that could be right, but only one
    >*right* answer is very rare.

    I believe that one right answer is not what I seek. Rather, I seek one
    resource that has a set of "approved" answers by a community and/or whose
    content will be continually reviewed and updated over time. "One resource"
    in this case could be a single website with multiple mechanisms to an
    individual to propose documentation content for it to be implicitly
    reviewed and changed if a review community finds discrepancies.

    As for the various solutions:

    There could be a use-postfix-with-courier-imap-and-mysql-without-sasl2 page
    (which I'm currently doing) that could cross-reference more
    pages. Alternative viewpoints could both be presented in the same
    article. Discussions could be linked via a email list (like this one)
    and/or a web forum (even better with thread links) or both (via something
    like mail2forum.com or CM2F).

    IF (and this may be a big if) this is suitable, why does this community not
    crawl all over a postfix-based wiki and make it their own, advertise it to
    new potential admin-users, etc. It seems to me that this would make
    postfix all that more attractive to new users trying to do the "do a I
    choose exim/qmail/sendmail/courier/postfix?" thing.

    I'm using these mechanisms in my corporate software development group
    seemingly quite effectively. In fact, I have trouble thinking how I could
    get by without it.

    Alas, it hasn't happened...so I'm curious if Keith's above points and/or
    other dynamics have kept it from happening.

    >I would add that if there is a single point then it tends to express a
    >single viewpoint only. Wikipedia is getting to be a classic example of
    >that where there are people who care more about having the style correct
    >than they do about having correct information (not to mention those who
    >think that one country's terminology is the only *right* one to use).

    I haven't yet experienced that in the Wikipedia technical articles (and
    some of them have saved me big time, or at least the ones on
    meta.wikimedia.org), but that's interesting.

    -Matt


  • Next message: /dev/rob0: "Re: Name service error for name=yahoo.com"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD