-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 hi andy,
> Breaking out flamethrower..... :-) heh. > The official SA rules are meant to be used by all users. SARE on the > other hand is "Here's the rules we have, go ahead and pick and choose what > you'd like to use. If anything" true. agreed. tangential to the discussion. > SARE makes new rules available in a quick fashion that may > eventually make their way into the official SA rules. my argument is that "eventually" has arrived. >> from a user's perspective, all this is confusing/confounding. as a >> user, i want to see/use one mechanism for rules. > > Works rather well for me, no confusuion involved. RDJ has my list of > rules. If it finds an update, it downloads it. SAupdate I'll manually run > about once every couple weeks. as it does for me. and for many others on this list. and you're speaking - -- i'll argue -- as an admin. but it is "yet another functional add on that's required" ... to bret's argument, and mine, the environment is unnecessarily complex. particularly now that sa-update *is* an available delivery mechanism. the 'sa vs rdj' thread has been an argument, imho, about the wrong argument. >> quite clearly, with the advent of SA-project released/blessed sa-update, >> it's not really necessary anymore. i.e., asynchronous rule & code >> releases are provided for. > > I think SARE can put out a new rule for a specific spam problem a lot > faster than the SA project, so I'll have to disagree with you here. huh? i'm talking about the DELIVERY mechanism of sa-update, NOT the rule source. >> SA *is* about managing/processing rules after all! ... > > And SARE is a set of OPTIONAL, add on rules. Once installed, SA processes > them very well. again, i'm talking about the delivery mechanism. > Are optional addons to IE all installed the same way? No. How about SA > itself. You've got CPAN, tarball, ports, packages, RPMs etc. etc. etc. I > have at least four different ways of installing the OPTIONAL SA package > onto my FreeBSD system. We are admins after all, not end users. apples and oranges. all your examples are generic functionalities/tools that have multiple other uses as well. and they are all making it possible to install and conform with the official SA release, its tools & capabilities. sa-update, rdj & sare *all*deal with one thing --- well two --- rule creation & rule delivery. and, the OTHER project in this discussion -- SARE -- leaning on your own argument, is pointedly NOT undertaking to use/conform to sa's 'official' tools & capabilities -- namely, sa-update as a delivery mechanism. times change. so has SA. sa-update is now available. adapt! finally, if, as an admin, you're arguing than unnecessary complexity is a good thing, then someone's paying you too much :-p (we won't tell ...) > Flame thrower extinguished. > >> </ removing tin-foil hat and asbestos shorts ... but keeping them >> readily available> whew! nothing singed! richard - -- /"\ \ / ASCII Ribbon Campaign X against HTML email, vCards / \ & micro$oft attachments [GPG] OpenMacNews at gmail dot com fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iEYEAREDAAYFAkTcutwACgkQlffdvTZxCMamGgCfYNFdDbx1mn1Mi200b8dmRSWf GtcAoKewavDxUtacdmpfSy3ZboGbgp1k =CKLZ -----END PGP SIGNATURE-----
