Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

mysql viability (was: shells and bells)

	 This is not the way things are done.  In the "real world," the database is
	 part of the infrastructure and it is common to all projects.  This allows
	 it to be managed, backed up, and so forth.  Choosing a database server on
	 a per-project basis is like choosing your mail transport agent on a
	 per-message basis.  "Well, this one is going to a mailing list, so I guess
	 we can send it with exim.  And this one is going to someone whose machine
	 is unreliable, so we should use Sendmail."  You see my point?

No; I do that sort of thing all the time. ;-)

"Hey, that message bounced and the garbage  that  came  back  doesn't
explain anything.  Well, let's try sendmail -v ...  Hmmm; that wasn't
too informative either; let's try it with ..."

I do have a couple of perl and expect  scripts  that  know  something
about  SMTP  and  can deliver a message with lots of extra info about
what's going wrong. They come in handy when the default mail delivery
thingies fail.

Sometimes I send mail with a "telnet $host 25" command.

Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at (Subject line is ignored).

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /