(Mason, btw, is a templating system written in Perl)
Postfix for speed
on
Postfix
·
· Score: 4, Informative
While a lot of the comments here (at least those +3 and above) mention Postfix's ease of management vs. that of Sendmail, one point that hasn't received a lot of attention is how the two compare in terms of efficiency. My experience with Sendmail in a high-load environment tells me it's a monolithic, bloated, resource pig. But that was when I was still somewhat new to the admin game, so I'm sure with some expertise it can be tuned.
Postfix, on the other hand, 'out of the box' was wonderful, (not to mention easy to use) and when I learned to tune things like filesystem parameters, optimal disk subsystem layout, and such it only got better. Our Postfix installation where I work continues to amaze me with how much mail it processes each day, with little or no maintenance, even under heavy load (1M+ incoming messages/day between 5 dual-CPU, 2-disk SCSI PIII-class machines). My gut feeling is that with some beefier boxes, and a pile of disks I could get that down to 2 machines handling the same amount of traffic.
Another plus for Postfix is its flexibility, and, if you need to get so deep, its hackability. The code is extremely clean, modular, and easy to work with.
Business rules belong in the database, not in the middle tier! Databases should be application independent. You introduce too many ways to screw up your data when you enforce your rules in some tier outside the database. Think about it, if you have to implement your business rules in every application that talks to the database, what a nightmare. Yes, you could put all that into some middle tier, and make sure that any access to the database goes through that tier, but then you have to enforce that.
And often, it's not via triggers or stored procedures, but I'd wager a good chunk of your business rules can be implemented through good relational design, with proper normalization and keys in place.
See www.dbdebunk.com, Or check out any of the stuff written by C. J. Date or Fabian Pascal.
Although my vote would be for Postgresql as well, by some standards (C.J. Date, and Fabian Pascal--see http://www.dbdebunk.com) Postgres isn't a 'real' RDBMS either. By those same standards, Oracle doesn't qualify as well. They fall into the class of database systems known as SQL-DBMSs. SQL wasn't fully relational to start with.
Most of what's on the market today doesn't faithfully implement the relational model--and mainly because of everyone's dependence on SQL.
Slashdot Mirror
Is Amazon big-name enough for you?
http://www.masonhq.com/?AmazonDotCom
(Mason, btw, is a templating system written in Perl)
While a lot of the comments here (at least those +3 and above) mention Postfix's ease of management vs. that of Sendmail, one point that hasn't received a lot of attention is how the two compare in terms of efficiency. My experience with Sendmail in a high-load environment tells me it's a monolithic, bloated, resource pig. But that was when I was still somewhat new to the admin game, so I'm sure with some expertise it can be tuned.
Postfix, on the other hand, 'out of the box' was wonderful, (not to mention easy to use) and when I learned to tune things like filesystem parameters, optimal disk subsystem layout, and such it only got better. Our Postfix installation where I work continues to amaze me with how much mail it processes each day, with little or no maintenance, even under heavy load (1M+ incoming messages/day between 5 dual-CPU, 2-disk SCSI PIII-class machines). My gut feeling is that with some beefier boxes, and a pile of disks I could get that down to 2 machines handling the same amount of traffic.
Another plus for Postfix is its flexibility, and, if you need to get so deep, its hackability. The code is extremely clean, modular, and easy to work with.
No!
Business rules belong in the database, not in the middle tier! Databases should be application independent. You introduce too many ways to screw up your data when you enforce your rules in some tier outside the database. Think about it, if you have to implement your business rules in every application that talks to the database, what a nightmare. Yes, you could put all that into some middle tier, and make sure that any access to the database goes through that tier, but then you have to enforce that. And often, it's not via triggers or stored procedures, but I'd wager a good chunk of your business rules can be implemented through good relational design, with proper normalization and keys in place.
See www.dbdebunk.com,
Or check out any of the stuff written by C. J. Date or Fabian Pascal.
"I moved to PGSQL because it was a 'real RDBMS.'"
Although my vote would be for Postgresql as well, by some standards (C.J. Date, and Fabian Pascal--see http://www.dbdebunk.com) Postgres isn't a 'real' RDBMS either. By those same standards, Oracle doesn't qualify as well. They fall into the class of database systems known as SQL-DBMSs. SQL wasn't fully relational to start with.
Most of what's on the market today doesn't faithfully implement the relational model--and mainly because of everyone's dependence on SQL.
I've got an old Wyse-50. Any chances I could use that as a terminal? Point me to any recommended HOWTO's etc. Thanks in advance.