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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]>: > > > > > 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:[EMAIL PROTECTED]] > > > > > > 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