It is an incredibly simple site, and all of the content is actually just static files. Rails isn't handling any loads, its just generating an html file and the webserver is serving that. Maybe if the forum were in rails you would have a point, but its still php.
Wasting time having to write unit tests to compensate for a languages shortcomings is just silly. Why not simply use a decent language to start with? I've seen tons of bugs (python in this case) from dynamic typing. The only disadvantage of a statically typed language is a couple extra keystrokes (int foo instead of foo), so why not use one?
You can call it a solution all you want, but its not. You said adding transactions is easy, and then explained how to impliment a WAL. That does not make transactions, it just lets you recover if something fucks up.
"but every database considers a rollback as a form of recovery"
Uh, no. MVCC keeps changed rows in the table, so a rollback simply changes which row is "active". There is no need to be doing something stupid like replaying logs just to do a simple rollback on a single failed transaction. While I do not doubt that some database does this, your assertion that every database does this is not only completely rediculous, but demonstrates your total ignorance of the subject.
And of course, your performance claim is made while conveniently ignoring the fact that if you try to roll your own fake transactions, you still have to lock tables to prevent dirty or phantom reads and other problems, which leads to huge performance problems that real databases don't have.
"If either statement fails or the server crashes, the journal is hot. Recover: Close database. Recover database from last checkpoint. Open database. Apply all completed (BEGIN-END) transactions from journal.
You are now back where you started."
Many combonations Elizagerth. You have succeeded in exhausting my patience. Which part of "Sure, you can take the whole fucking database offline and restore from a partial log, but that is absolutely retarded, and not transactions, its recovery." is so hard to grasp? Are you seriously suggesting people take their entire fucking database offline to restore it anytime a query fails? And you call that transactions? Give me a break.
No, I am not changing anything. Read it again. I said that if you try to create pseudo transactions above the db, they are not safe because either side can crash and leave things half done. Why do you insist on arguing if you can't even be bothered to read my posts?
And now you are simply talking insane nonsense. You need to be able to do this:
update accounts set balance = balance + 100 where id = 5 update accounts set balance = balance - 100 where id = 6
And be able to 100% guarentee that either both queries suceeded, or none of them did. Sure, you can take the whole fucking database offline and restore from a partial log, but that is absolutely retarded, and not transactions, its recovery. Transactions mean if query 2 fails, I can say "rollback", and query 1 never happened. And this is just the most basic possible example.
There is nothing magic about this at all, and yet you cannot seem to comprehend the basics of what transactions are, nevermind how to safely impliment them.
No, that's not difficult to understand. Nor does it solve the problem. I guess its easy to pretend to solve problems if you don't even understand them to begin with huh?
You are talking about making it possible to recover from a crash. The problem is a lack of transactional integrity. IE, you can roll back a series of queries if one fails.
Mysql had no "journal" back then. And no, transactions cannot be implimented above the database, and I just explained why. Is there some special reason you must ignore not only my post, but also common sense, and make a rediculous reply anyways?
What does memory corruption have to do with anything? Read the mysql posting. Ron ignorantly (and incorrectly) states that mysql's lack of transations didn't matter because they can easily roll their own. This is nonsense, you cannot roll your own because if your app dies, or the db dies in the middle of one of your pseudo-transactions, then your data is left in an inconsistant state. So your pretend transactions aren't actually giving you the basic guarentee that transactions are for.
And mods, how can you possibly mod an AC with a nonsense post about who knows what as informative? Give your head a shake, seriously.
Comment by the pros? Ron isn't a database guru by any stretch, and in the comments he even ignorantly states that mysql not having transactions (it didn't at that time) didn't matter because you can easily "roll you own".
This isn't a small business using mysql because they don't need features, this is google, and they needed features that mysql didn't have. They used stupid and unsafe hacks to partly work around it instead of simply using a real database.
Of course it was a pain to move to a real DB after the fact, that's why you shouldn't do things wrong in the first place.
Good fucking lord, does PHP damage your brain?
on
PHP 5.1.0 Released
·
· Score: 1
Why are all you PHP apologists so incredibly stupid? Not having a from argument does not make things easier at all, you can have optional arguments you know. So if you didn't specify a from arg, then it will use the (often undesirable) webserver user as its from.
I have a handle on this quirk because of getting spam complaints due to people putting exploitable PHP contact forms on webservers I admin. Duh? You have never heard of web hosting before?
"If a newb doesn't know what a header is, chances are the newb shouldn't be trying to fuck with 'em."
EXACTLY THE FUCKING POINT. PHP's mail function is creating the headers for to, and subject, so that users don't have to. It needs to be able to make a from header too. Its stupid for a high level language like PHP to require users to know the inner workings of mail headers. If you have to know what a valid mail header is and how to validate them, then you can just pipe directly to sendmail, so why is there even a mail() function at all?
And of course, this is the second problem. PHP's mail function is simply broken, plain and simple. It is NOT the web developers job to ensure the mail headers are valid, because they are not creating the headers. PHP's mail function is generating invalid mail headers (for the args it does support like subject), that's the PHP developers fault, not the fault of the people using PHP.
I don't think there is a problem with giving a little power to a newb, why do you insist on making irrational assumptions based on your warped prejudices? I think there is a problem with programmers writing broken, stupid code and then blaming other people for it. You claim to "have this thing" about taking personal responsability for being a shitty programmer, but yet insist on blaming the user for problems in PHPs code. If its PHP that is generating the header, then its PHP's job to ensure it is valid. And you cannot have \r\n in a valid mail header. This is the fault of the PHP developer who wrote mail(), and every PHP developer since who hasn't fixed it.
"Okay, perhaps I went too far it jumping right to HTML (or "any other SGML markup", I don't really care which - The distinction doesn't matter here)."
I was making the destinction because saying "HTML or XML" doesn't make sense. XML and SGML are on the same "level". Just like HTML and XHTML are. HTML being the SGML markup created for web, and XHTML being the XML markup created for web. None of the above are programming languages, however you could make a programming language on top of either SGML or XML.
"Perl - I don't think anyone would disagree that this counts as a programming language, yet you can't distinguish between the source code and the executable code, because it (almost) always runs under interpretation (well, okay, compiled Perl does exist, but as more of a curiosity than anything really used). Would the French really outlaw the second most commonly used programming language on the planet?"
Well, the wording is about licenses, not about wether or not the source code and the executable are seperate. And its not the French, its the French version of the RIAA.
"If you want to set an arbitrary limit such as "general recursive", fine, we can do that. But don't think that politicians grasp that distinction, nor will any law explicitly consider it"
Why would you assume that? Laws explicitly consider things like this all the time. There are legal definitions for all sorts of things, why would programming languages be different? We define what is murder, what is theft, what is a "weapon" in the context of assault charges. So why wouldn't they also define what is a programming language if they tried to outlaw one (which isn't the case here anyways)?
Python and bash do not go together like that. Python source code is in fact compiled into python bytecode (or java bytecode if you wish) and executed in that form, shells don't do this, they just interpret the commands line by line as they go.
There's more to what is a programming language and what isn't than simply being executed though, I was simply pointing out that what he was saying was wrong. And while XSLT may well qualify as a programming language, it is not XML. XML is a markup language, creating a programming language (XSLT) on top of XML doesn't turn XML into a programming language.
"I very deliberately said "HTML" because you write it as text, and it magically turns into something else when interpreted in the correct way."
Uh huh, but how is that different from any other SGML markup exactly? HTML is not a special magical SGML markup, by definition any other SGML markup can do anything HTML can.
Your point has already been dealt with in the past anyways. We already define what a programming language is and is not. Distinctions are made between different kinds of computer languages (programming languages, markup languages, etc) right now.
We'll pretend you said SGML and XML first of all. Now then, SGML and XML are not programming languages, and cannot be used to create programs. They are not executed.
You are right about software use and how copyright holders can't restrict you in that way. But running a GPL webserver for instance could be considered a public display/performance of the copyrighted work, and it could be restricted that way.
But saying that he doesn't always comment is not saying "never comment, commenting is bad", which is what the other poster somehow takes away from it. I do comment sometimes, and then giving examples of when he thinks commenting is helpful is most certainly encouraging commenting. Its simply discouraging USELESS commenting, which is WAY too common.
And FYI, an ad hominem attack is attacking someone, instead of attacking their argument. I clearly pointed out the flaws in his argument, and only called him a dumbass who refuses to read after he ignored everything I said and repeated the same nonsense. That's not ad hominem at all.
"Riiight. That's very misleading, if not outright misinformation. Yes, in certain situations Apache-httpd can happily flood the LAN connection... but it can have huge problems with non-instant connections due to the one process per. connection model, it is also esp. bad when the number of connections goes high. And in more situations Apache-httpd being slow isn't your major bottleneck. But you can't say "it performs very well" with a straight face."
You are just plain uninformed. "certain situations" include almost all real world situations. Name a situation where apache can't serve files fast enough, but something else can. People have "preformance" problems with apache because they do things like write horrible slow PHP, and then complain that apache is slow. If you have slow shitty PHP code, then it will be slow. But that's not apache. And obviously apache is not tied to a single connection per process, I'm not sure why you think that.
"Useful is in the eye of the beholder, a significant number of people are fine with what thttpd provides... personally I find that it's horrible to do things in apache-httpd that are easy in And-httpd. But then the developer staff are very open to my needs in the later:)."
My comment was that its not a fair comparison for you to sit there and talk about how perfect your webserver is, when all it can do is move files from disk to network. When you approach the functionality of lighttpd, then you can compare your respective security track records.
Re:Are you reading the same thing I am?
on
How to Write Comments
·
· Score: 0, Flamebait
Quoting a dumbass who refuses to read what he replies to: "I assume all these people are now working with you and Rob Pike."
Quoting the post you replied to, and even quoted: "The people I am surrounded by are not making the comments, the mass of assorted dumbasses all over the world are."
"If you think Pike is for comments, perhaps you can point out what paragraph actually encourages commenting in his article,"
I already did, remember: "Almost exclusively, I use them as an introduction to what follows. Examples: explaining the use of global variables and types (the one thing I always comment in large programs); as an introduction to an unusual or critical procedure; or to mark off sections of a large computation."
But obviously reading what you reply to takes WAY too much effort.
Re:Are you reading the same thing I am?
on
How to Write Comments
·
· Score: 0, Flamebait
"I don't. I see them occasionally. You're either surrounded by complete idiots, or elite programmers making jokes that are flying above your head."
Or perhaps you are making stupid assumptions. Yes, I deal with alot of shitty code, most of it open source and written by people I have never even met. The people I am surrounded by are not making the comments, the mass of assorted dumbasses all over the world are. But of course, it must be just me and that wacky nut Rob Pike, we're both such shitty programmers that our experiences would be irrelivant.
As for the rest of your post, you just like to argue it seems. You are reading into his words and mine the intent you would like to see, simply so you can disagree with it. Since you don't actually need anyone else for this, why not just go make up both sides to an argument on your own?
I see comments EXACTLY like this: i=i+1;/* Add one to i */ ALL THE TIME. It is incredibly annoying, and trains your eye to ignore all comments, so you miss the occasional useful one. If you don't see comments like that in real life, then you are without a doubt the luckiest programmer alive.
"It doesn't take much, or add any clutter to code, to put a brief, one or two line, comment before each paragraph of code, that describes the intended functionality of the code block. It makes a massive difference when you revisit your code three years, or even three months, later, or worse have a collegue look at it. "
Oh, you mean kinda like he said he does do, and is what comments should be used for? Did you skip over this part: "But I do comment sometimes. Almost exclusively, I use them as an introduction to what follows. Examples: explaining the use of global variables and types (the one thing I always comment in large programs); as an introduction to an unusual or critical procedure; or to mark off sections of a large computation."?
And yes, code should be mostly self documenting. The exceptions should be few and far between, and should be commented as appropriate. Its amazing that you read his statement which could be summed up as "Reasonable, non-excessive, use of comments, describing functionality rather than function", and somehow managed to disagree, and summarize your opposition as "Reasonable, non-excessive, use of comments, describing functionality rather than function".
Second, yes it did have a stupid error that less you use NULL to see a file's source instead of interpreting it. Of course, you shouldn't have your source in a web accessable directory anyhow, that's one of the major benefits of fastcgi. It would be nice if people would stop writing things and calling them "secure" when they aren't actually trying very hard to write secure code, but there's definately alot worse out there than lighttpd. Its no worse than apache, which is what most people are running anyways.
Third, does your webserver support any of the stuff lighttpd does, or is it just like thttpd (not terribly useful)?
And finally, where is this buffer overflow exactly? I certainly don't consider myself a C expert, but although the code is "wrong", I don't see any way to overflow salt.
Actually, building PHP with fastcgi support requires neither of those things. Just set CONFIGURE_ARGS to whatever you want it to be before building the port. Its not that big a deal is it?
Also, have you asked the maintainer to include a fastcgi FLAVOR?
Slashdot Mirror
It is an incredibly simple site, and all of the content is actually just static files. Rails isn't handling any loads, its just generating an html file and the webserver is serving that. Maybe if the forum were in rails you would have a point, but its still php.
Wasting time having to write unit tests to compensate for a languages shortcomings is just silly. Why not simply use a decent language to start with? I've seen tons of bugs (python in this case) from dynamic typing. The only disadvantage of a statically typed language is a couple extra keystrokes (int foo instead of foo), so why not use one?
"You can dislike the solution all you want"
You can call it a solution all you want, but its not. You said adding transactions is easy, and then explained how to impliment a WAL. That does not make transactions, it just lets you recover if something fucks up.
"but every database considers a rollback as a form of recovery"
Uh, no. MVCC keeps changed rows in the table, so a rollback simply changes which row is "active". There is no need to be doing something stupid like replaying logs just to do a simple rollback on a single failed transaction. While I do not doubt that some database does this, your assertion that every database does this is not only completely rediculous, but demonstrates your total ignorance of the subject.
And of course, your performance claim is made while conveniently ignoring the fact that if you try to roll your own fake transactions, you still have to lock tables to prevent dirty or phantom reads and other problems, which leads to huge performance problems that real databases don't have.
"If either statement fails or the server crashes, the journal is hot. Recover:
Close database.
Recover database from last checkpoint.
Open database.
Apply all completed (BEGIN-END) transactions from journal.
You are now back where you started."
Many combonations Elizagerth. You have succeeded in exhausting my patience. Which part of "Sure, you can take the whole fucking database offline and restore from a partial log, but that is absolutely retarded, and not transactions, its recovery." is so hard to grasp? Are you seriously suggesting people take their entire fucking database offline to restore it anytime a query fails? And you call that transactions? Give me a break.
No, I am not changing anything. Read it again. I said that if you try to create pseudo transactions above the db, they are not safe because either side can crash and leave things half done. Why do you insist on arguing if you can't even be bothered to read my posts?
And now you are simply talking insane nonsense. You need to be able to do this:
update accounts set balance = balance + 100 where id = 5
update accounts set balance = balance - 100 where id = 6
And be able to 100% guarentee that either both queries suceeded, or none of them did. Sure, you can take the whole fucking database offline and restore from a partial log, but that is absolutely retarded, and not transactions, its recovery. Transactions mean if query 2 fails, I can say "rollback", and query 1 never happened. And this is just the most basic possible example.
There is nothing magic about this at all, and yet you cannot seem to comprehend the basics of what transactions are, nevermind how to safely impliment them.
No, that's not difficult to understand. Nor does it solve the problem. I guess its easy to pretend to solve problems if you don't even understand them to begin with huh?
You are talking about making it possible to recover from a crash. The problem is a lack of transactional integrity. IE, you can roll back a series of queries if one fails.
Yes, I did explain why. If you don't feel like reading, then don't bother replying.
And as for the rest of your blather, either step up and explain how you can make the mysql of 2000 guarenteed safe with transactions, or stfu.
Mysql had no "journal" back then. And no, transactions cannot be implimented above the database, and I just explained why. Is there some special reason you must ignore not only my post, but also common sense, and make a rediculous reply anyways?
What does memory corruption have to do with anything? Read the mysql posting. Ron ignorantly (and incorrectly) states that mysql's lack of transations didn't matter because they can easily roll their own. This is nonsense, you cannot roll your own because if your app dies, or the db dies in the middle of one of your pseudo-transactions, then your data is left in an inconsistant state. So your pretend transactions aren't actually giving you the basic guarentee that transactions are for.
And mods, how can you possibly mod an AC with a nonsense post about who knows what as informative? Give your head a shake, seriously.
Comment by the pros? Ron isn't a database guru by any stretch, and in the comments he even ignorantly states that mysql not having transactions (it didn't at that time) didn't matter because you can easily "roll you own".
This isn't a small business using mysql because they don't need features, this is google, and they needed features that mysql didn't have. They used stupid and unsafe hacks to partly work around it instead of simply using a real database.
Of course it was a pain to move to a real DB after the fact, that's why you shouldn't do things wrong in the first place.
Why are all you PHP apologists so incredibly stupid? Not having a from argument does not make things easier at all, you can have optional arguments you know. So if you didn't specify a from arg, then it will use the (often undesirable) webserver user as its from.
I have a handle on this quirk because of getting spam complaints due to people putting exploitable PHP contact forms on webservers I admin. Duh? You have never heard of web hosting before?
"If a newb doesn't know what a header is, chances are the newb shouldn't be trying to fuck with 'em."
EXACTLY THE FUCKING POINT. PHP's mail function is creating the headers for to, and subject, so that users don't have to. It needs to be able to make a from header too. Its stupid for a high level language like PHP to require users to know the inner workings of mail headers. If you have to know what a valid mail header is and how to validate them, then you can just pipe directly to sendmail, so why is there even a mail() function at all?
And of course, this is the second problem. PHP's mail function is simply broken, plain and simple. It is NOT the web developers job to ensure the mail headers are valid, because they are not creating the headers. PHP's mail function is generating invalid mail headers (for the args it does support like subject), that's the PHP developers fault, not the fault of the people using PHP.
I don't think there is a problem with giving a little power to a newb, why do you insist on making irrational assumptions based on your warped prejudices? I think there is a problem with programmers writing broken, stupid code and then blaming other people for it. You claim to "have this thing" about taking personal responsability for being a shitty programmer, but yet insist on blaming the user for problems in PHPs code. If its PHP that is generating the header, then its PHP's job to ensure it is valid. And you cannot have \r\n in a valid mail header. This is the fault of the PHP developer who wrote mail(), and every PHP developer since who hasn't fixed it.
From the openbsd mplayer port's Makefile:
ONLY_FOR_ARCHS= amd64 i386 powerpc sparc64 arm
As it was explained repeatedly now, its just the win32 binary codecs are i386 only.
"Okay, perhaps I went too far it jumping right to HTML (or "any other SGML markup", I don't really care which - The distinction doesn't matter here)."
I was making the destinction because saying "HTML or XML" doesn't make sense. XML and SGML are on the same "level". Just like HTML and XHTML are. HTML being the SGML markup created for web, and XHTML being the XML markup created for web. None of the above are programming languages, however you could make a programming language on top of either SGML or XML.
"Perl - I don't think anyone would disagree that this counts as a programming language, yet you can't distinguish between the source code and the executable code, because it (almost) always runs under interpretation (well, okay, compiled Perl does exist, but as more of a curiosity than anything really used). Would the French really outlaw the second most commonly used programming language on the planet?"
Well, the wording is about licenses, not about wether or not the source code and the executable are seperate. And its not the French, its the French version of the RIAA.
"If you want to set an arbitrary limit such as "general recursive", fine, we can do that. But don't think that politicians grasp that distinction, nor will any law explicitly consider it"
Why would you assume that? Laws explicitly consider things like this all the time. There are legal definitions for all sorts of things, why would programming languages be different? We define what is murder, what is theft, what is a "weapon" in the context of assault charges. So why wouldn't they also define what is a programming language if they tried to outlaw one (which isn't the case here anyways)?
Python and bash do not go together like that. Python source code is in fact compiled into python bytecode (or java bytecode if you wish) and executed in that form, shells don't do this, they just interpret the commands line by line as they go.
There's more to what is a programming language and what isn't than simply being executed though, I was simply pointing out that what he was saying was wrong. And while XSLT may well qualify as a programming language, it is not XML. XML is a markup language, creating a programming language (XSLT) on top of XML doesn't turn XML into a programming language.
"I very deliberately said "HTML" because you write it as text, and it magically turns into something else when interpreted in the correct way."
Uh huh, but how is that different from any other SGML markup exactly? HTML is not a special magical SGML markup, by definition any other SGML markup can do anything HTML can.
Your point has already been dealt with in the past anyways. We already define what a programming language is and is not. Distinctions are made between different kinds of computer languages (programming languages, markup languages, etc) right now.
We'll pretend you said SGML and XML first of all. Now then, SGML and XML are not programming languages, and cannot be used to create programs. They are not executed.
Forcing monitors to duel is cruel and inhumane. This blood sport should be outlawed and people like you put in jail!
You are right about software use and how copyright holders can't restrict you in that way. But running a GPL webserver for instance could be considered a public display/performance of the copyrighted work, and it could be restricted that way.
But saying that he doesn't always comment is not saying "never comment, commenting is bad", which is what the other poster somehow takes away from it. I do comment sometimes, and then giving examples of when he thinks commenting is helpful is most certainly encouraging commenting. Its simply discouraging USELESS commenting, which is WAY too common.
And FYI, an ad hominem attack is attacking someone, instead of attacking their argument. I clearly pointed out the flaws in his argument, and only called him a dumbass who refuses to read after he ignored everything I said and repeated the same nonsense. That's not ad hominem at all.
"Riiight. That's very misleading, if not outright misinformation. Yes, in certain situations Apache-httpd can happily flood the LAN connection ... but it can have huge problems with non-instant connections due to the one process per. connection model, it is also esp. bad when the number of connections goes high. And in more situations Apache-httpd being slow isn't your major bottleneck. But you can't say "it performs very well" with a straight face."
... personally I find that it's horrible to do things in apache-httpd that are easy in And-httpd. But then the developer staff are very open to my needs in the later :)."
You are just plain uninformed. "certain situations" include almost all real world situations. Name a situation where apache can't serve files fast enough, but something else can. People have "preformance" problems with apache because they do things like write horrible slow PHP, and then complain that apache is slow. If you have slow shitty PHP code, then it will be slow. But that's not apache. And obviously apache is not tied to a single connection per process, I'm not sure why you think that.
"Useful is in the eye of the beholder, a significant number of people are fine with what thttpd provides
My comment was that its not a fair comparison for you to sit there and talk about how perfect your webserver is, when all it can do is move files from disk to network. When you approach the functionality of lighttpd, then you can compare your respective security track records.
Quoting a dumbass who refuses to read what he replies to:
"I assume all these people are now working with you and Rob Pike."
Quoting the post you replied to, and even quoted:
"The people I am surrounded by are not making the comments, the mass of assorted dumbasses all over the world are."
"If you think Pike is for comments, perhaps you can point out what paragraph actually encourages commenting in his article,"
I already did, remember:
"Almost exclusively, I use them as an introduction to what follows. Examples: explaining the use of global variables and types (the one thing I always comment in large programs); as an introduction to an unusual or critical procedure; or to mark off sections of a large computation."
But obviously reading what you reply to takes WAY too much effort.
"I don't. I see them occasionally. You're either surrounded by complete idiots, or elite programmers making jokes that are flying above your head."
Or perhaps you are making stupid assumptions. Yes, I deal with alot of shitty code, most of it open source and written by people I have never even met. The people I am surrounded by are not making the comments, the mass of assorted dumbasses all over the world are. But of course, it must be just me and that wacky nut Rob Pike, we're both such shitty programmers that our experiences would be irrelivant.
As for the rest of your post, you just like to argue it seems. You are reading into his words and mine the intent you would like to see, simply so you can disagree with it. Since you don't actually need anyone else for this, why not just go make up both sides to an argument on your own?
I see comments EXACTLY like this: /* Add one to i */
i=i+1;
ALL THE TIME. It is incredibly annoying, and trains your eye to ignore all comments, so you miss the occasional useful one. If you don't see comments like that in real life, then you are without a doubt the luckiest programmer alive.
"It doesn't take much, or add any clutter to code, to put a brief, one or two line, comment before each paragraph of code, that describes the intended functionality of the code block. It makes a massive difference when you revisit your code three years, or even three months, later, or worse have a collegue look at it. "
Oh, you mean kinda like he said he does do, and is what comments should be used for? Did you skip over this part: "But I do comment sometimes. Almost exclusively, I use them as an introduction to what follows. Examples: explaining the use of global variables and types (the one thing I always comment in large programs); as an introduction to an unusual or critical procedure; or to mark off sections of a large computation."?
And yes, code should be mostly self documenting. The exceptions should be few and far between, and should be commented as appropriate. Its amazing that you read his statement which could be summed up as "Reasonable, non-excessive, use of comments, describing functionality rather than function", and somehow managed to disagree, and summarize your opposition as "Reasonable, non-excessive, use of comments, describing functionality rather than function".
First of all, it doesn't perform better than apache. It uses less memory than apache to serve many static files. Apache performs very well if configured correctly:4 /debunking-lighttpd?postid=82
http://paul.querna.org/journal/articles/2005/06/2
Second, yes it did have a stupid error that less you use NULL to see a file's source instead of interpreting it. Of course, you shouldn't have your source in a web accessable directory anyhow, that's one of the major benefits of fastcgi. It would be nice if people would stop writing things and calling them "secure" when they aren't actually trying very hard to write secure code, but there's definately alot worse out there than lighttpd. Its no worse than apache, which is what most people are running anyways.
Third, does your webserver support any of the stuff lighttpd does, or is it just like thttpd (not terribly useful)?
And finally, where is this buffer overflow exactly? I certainly don't consider myself a C expert, but although the code is "wrong", I don't see any way to overflow salt.
Actually, building PHP with fastcgi support requires neither of those things. Just set CONFIGURE_ARGS to whatever you want it to be before building the port. Its not that big a deal is it?
Also, have you asked the maintainer to include a fastcgi FLAVOR?