Time has come to stop with /usr/local path pollution!

[Tom Andrews]

I am new to cyrus and the info-cyrus mailing list, but am a long time unix
administrator and developer.  Sendmail offers a similar product to cyrus, but
lacking in some of the new features, for a large price tag.  I  prefer to deal
with a few compilation gliches, provided the software works reliably once
installed.

If I can contribute in any way, I will.  Thank you for making this software
publicly available.  I suspect it is far more popular than the developers
originally anticipated.
  
-- 
Tom Andrews
Team Leader / Server Manager
Campus Computing
University of Nevada, Reno

Quoting Paul Fleming <pfleming at siumed.edu>:

> I'm going to throw out my opinion too.. 
> 
> Please no flames. This isn't directed at anyone -- just my observations 
> after using/maintaining Cyrus for 4 years (v1.5.19 still in production) 
> 
> First, CMU places a nice disclaimer in the docs. Cyrus is on the same order
> of NetNews to install -- historically compiling/installing/maintaining news
> server software has been a daunting task at best. When we started w/ Cyrus
> (1998) it was a big departure from the traditional mbox mail system. Even
> today if you want a simple to install mailsystem use mbox+/var/mail.  Cyrus
> 
> is a much more robust system and as a result requires more time and
> experience 
> to install. Additionally, if you are trying to build a big mail system you 
> better have more experience than "I've installed Linux a few times." Building
> 
> large, scalable, and secure mail systems requires experience, patience and 
> usually lots of caffeine and little sleep. (subscribing to this list helps
> too)
> 
> Second, opensource does NOT work unless people contribute. CMU developed
> and
> maintains this software for their own use -- the rest of us get a free
> ride.
> I really appreciate the contributions Ken and others have made to the
> project. 
> If you find something you don't like/think needs changing do what the rest of
> 
> us do - change it and contrib it back to CMU. The current group of Cyrus 
> developers have been great w/ working with outside patches etc. (users
> since
> v1 will remember those days when CMU was just trying to make it work ;-) )
> 
> Cyrus has been instrumental in our organizations conversion to opensource. 
> Without Cyrus, we'd be running Groupwise or M$ Exchange ick! If Cyrus is
> too
> complicated / difficult for you to install/maintain go hire someone who can
> or purchase one of the above mentioned packages. 
> 
> Some important points:
> 
> 1) Many thanks to CMU for releasing and trying to support this great
> software.
> 
> 2) You get what you pay for (in this case remember the code is free)
> 
> 3) If it breaks -- you get to keep both pieces -- but ask nicely many of us
> have
> broken Cyrus too.
> 
> 4) Participate -- subscribe to the list, submit docs fixes etc if you can,
> discuss 
> issues on the list, don't post "bitching" about this or that unless you are
> 
> willing to do something about it.
> 
> 5) If you don't like #4 quit wasting our time..
> 
> Paul
> Satisfied Cyrus user & contributor since v1.5.14 
> 
> 
> On Sat, 28 Sep 2002, Ken Murchison wrote:
> 
> > Quoting Andrew Diederich <andrew at NETdelivery.com>:
> > 
> > > I'd just ask that if a known bug isn't going to be fixed, it needs to
> be
> > > documented and put upfront, big and large, where folks will see it.
> > > Shutting off compiler warnings with gcc 3.2 is an example.  It broke
> > > compile, but folks were talking about it on the list.  
> > > 
> > > Many of the developers, and people on this list, know about the
> problem,
> > > but
> > > people who just download the software, read the docs, and try to install
> it
> > > will get burned otherwise.  Then they'll curse the crappy software, and
> > > they'll be right.  
> > > 
> > > There are three things to do when a bug is found.  1) fix it, 2)
> document
> > > the bug and the workaround, or 3) hope people don't find it again.  #3
> is
> > > terribly expensive in support costs, like this string of emails.
> > 
> > Its seems that people are missing a very important point here.  Cyrus was
> 
> > developed for internal use at CMU.  CMU has been kind enough to allow the
> 
> > source code to be distributed for use by anybody, commercial or
> otherwise.
> > 
> > Some may argue that CMU has a responsibility to fix all bugs, write good 
> > documentation, hand-hold ignorant/illiterate admins, make coffee, and clean
> 
> > windows.  In most cases, they do all of the above, and more.
> > 
> > I wish people would keep this in mind, when they claim that the build
> process 
> > is broken.  It is broken for _you_, because I can assure you that it built
> for 
> > the intended user (CMU).  The developers first responsibilty is to their 
> > employers, not to a small, whiny part of the user community with an
> edge-case 
> > problem.
> > 
> > If people spend the same amount of time trying to fix the problem instead
> of 
> > bitching about it, this would've been a dead issue a long time ago.  It
> don't 
> > think that the "squeaky wheel gets the grease" principal is necessarily
> going 
> > to work.
> > 
> > The next time somebody is frustrated by the software and wants to rant
> about 
> > how much of their time the developers wasted, take a step back and remember
> how 
> > much time and money they actually _saved_ you.
> > 
> > Another $.02
> > 
> > 
> > > -----Original Message-----
> > > From: Rob Siemborski [mailto:rjs3 at andrew.cmu.edu]
> > > 
> > > On Fri, 27 Sep 2002, Michael Newlyn Blake wrote:
> > > 
> > > > However it does seem that when explicit paths are called for certain
> > > > componants they should be placed in line before the assumed system
> paths.
> > > > That is to say, if you want to build and link against a libfoo in
> > > > /snert/myjunk/foo-8.3.4 then this should be placed in the relevant
> paths
> > > > before the include and lib dirs in /usr or /usr/local that are added
> > > > automatically.
> > > 
> > > I agree 100% that the paths should be honored.  However, since it works
> > > for most people, and testing is pretty annoying (as ken stated), I'm
> not
> > > terribly eager to spend my time doing it, when I could be working on
> > > performance or feature improvements elsewhere in the code.
> > > 
> > > If there was a patch provided that I could look at, approve, and apply,
> > > I'd be willing to do so.  This is much less the case if I'm going to
> have
> > > to read a bug report hidden inside of a rant that seems to assume that
> the
> > > developers of Cyrus are part of a consipracy against all system
> > > administrators everywhere.
> > > 
> > > -Rob
> > > 
> > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
> > > Research Systems Programmer * /usr/contributed Gatekeeper
> > > 
> > > 
> > > 
> > 
> > 
> > -- 
> > Kenneth Murchison     Oceana Matrix Ltd.
> > Software Engineer     21 Princeton Place
> > 716-662-8973 x26      Orchard Park, NY 14127
> > --PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp
> > 
> 


-------------------------------------------------
This mail sent through https://webmail.unr.edu