 |
chod's other blog |
An online journal... |
|
Hosts Disable Movable Type as Comment Spam Slows Servershttp://news.netcraft.com/archives/2004/12/17/hosts_disable_movable_type_as_comment_spam_slows_servers.html Shamelessly stolen from Slashdot. Huh, look at that...we're running movabletype... Can anyone say b2evolution? TrackbacksTrackback URL for this entry is: http://blog.case.edu/bec/mt-tb.cgi/69 Fighting Blog SpamExcerpt: There's been some brouhaha over comment spam especially related to Movable Type, which is the publishing platform Blog@Case is based... Weblog: Jeremy Smith's blog Tracked: December 19, 2004 03:58 PM Post a comment |
Comments
b2evolution was evaluated and not chosen because it requires a new database for each blog. So, for n blogs, there would need to be n MySQL DBs. That would be a nightmare. (This is, also, the case with WordPress.)
Maybe I'll do a writeup on why MT was chosen. Maybe I will, first, do a writeup on what countermeasures the Blog@Case system has against comment and trackback spam.
[because it requires a new database for each blog.]
Hmmm, I am almost certain that is not correct. b2Evolution can power multiple blogs off of one central mySQL database.
For example, check out my friend's site which has six individual blogs as well as an aggregate blog which shows all the latest entries:
http://www.monkeysnest.com/blogs
The native implementation of b2Evolution supports the multiple blog feature (Blog A, B, etc.) which only requires a single mySQL database for the entire b2evolution install.
My blog also runs b2evolution, and I love the clean interface and ease of use:
http://www.benchodroff.com/blog
Hmmm, I might have confused b2evo with another of the blogging systems that were evaluated.
It looks like you mixed up wordpress with b2evo
Check out this blog entry:
http://www.ericjamesstone.com/blog/index.php/2004/11/24/whoa_what_happened
One of the comments points out the license limitations of MT, as well as the lack of multi-blog in wordpress
Oh, I remember why, now. b2evo used dynamically generated pages.
Even after setting up a chroot'ed Apache and setting PHP into safe mode, any user believing him or herself to be a 1337 h4X0r could DoS the server with a computationally intensive script. So, any publishing platform that used "fried" pages instead of "baked" pages were nixed (if that makes sense).
Ah, I see what you mean.