Slashdot Mirror
PHP 5.1.0 Released
kv9 writes "A new release of PHP5 is available. This version includes over 400 bugfixes, performance improvements over the 5.0.x branch, new date handling code, new versions of PCRE/SQLite/PEAR and over 30 new core/extension functions. A number of security fixes are also present and users are recommended to upgrade."
You mean, it sucks less than the previous versions, and the problems with inconsistent "design" decisions, half-assed attempts at support for objects, etc. have all been fixed?
Wow! I gotta' get me some of that...
Zend refuses to add basic features such as a basic accelerator ( PHP scripts get recompiled on every request ). In fact, there was a rumor that Zend bought and killed http://sourceforge.net/projects/turck-mmcache/, the best accelerator out there because it competed with their commercial product.
I understand that money has to be made for development to continue, but that's no way to compete.
PHP server needs true session and application scope variables. File-based session variables it has right now means that any variable that's not serializable ( eg. file descriptor ) can not be saved in the session scope. This is a huge problem. It results in developers making countless round trips to their database to serialize data, and hence making PHP scripts more dependant on close/performant database in general. There was an mmap based solution being worked on, but haven't heard much about it lately.
Other web environments have had these features for years.
I'm guessing that that sought of restriction on the PHP server will continue until an alternative server is developed and begins to gain popularity.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
I'd like to take this oppurtunity to complain about __autoload in PHP5. It is one functionality which I find tremendously inconvenient when coding something like APC . File inclusions were never supposed to be that dynamic, it ends up with different compilations of the same file for different places it is included in (apparently some are still fighting).
Quidquid latine dictum sit, altum videtur
The main reason for PHP being insecure is the huge amount of functions for "securing" form data before using it in an SQL query. It's just comical that both mysql_escape_string() and mysql_real_escape_string() exist. PHP should be purged from all of the unused and misused functions soon, or it will never be safe.
[sig]
Yes, but as Alan Perlis said in one of his epigrams...
Using your example, Perl is as complete as C, but IMHO interesting things are easier to do in Perl (or ruby, for that matter).
Some of us are trying to help the situation by educating PHP developers. For my part, I try to write articles (and make them available for free), give talks at conferences and user groups, and answer questions on mailing lists and forums.
There's also the PHP Security Consortium, the Zend Framework (which will hopefully include most things on my wishlist as well as solve other problems), and a new input filter extension.
As BP says, it's a start.
Relating to this comment:9 325&cid=14113043
h pp
http://developers.slashdot.org/comments.pl?sid=16
It's true that PHP suffers from various naming conventions, but namespaces might me the answer.
For PHP 6.0, does anyone know if the core developers are thinking of moving most builtin libraries into namespaces? For instance:
. . . http://ca.php.net/manual/en/function.oci-commit.p
could be placed in the "builtin\oci" namespace and
. . . http://ca.php.net/manual/en/function.ocicommit.ph
could be placed in the "builtin\legacy\oci" namespace.
You could quickly convert all PHP5 to PHP6 simply by adding the line:
. . . import builtin\*;
to the top of every file to make all builtin functions global (the way they are in PHP5).
Apps written in PHP5 would still work without the import, but they'd get a warning (which could be switches off in the php.ini).
Since when is language design a grad. discipline? The Zend guys happen to be damn good programmers - have a look at the code of the interpreter.
- IBM has spiffed up Cloudscape to be somewhat compatible to DB2, renamed it to Derby and is giving it away
- Oracle is giving away a mildly crippled version of its DB, I don't remember the exact circumstances
- ADABAS, also known as SAP DB, is now also FOSS
- Firebird, née Interbase, was freed years ago and is said to be working well and under active development. I don't know why so few people seem to like it.
- I believe I heard about SQL Server being "free" under some circumstances too, but I'm not sure.
So... many thanks to MySQL for being a forerunner in the "free DB" department, and more thanks to other, formerly proprietary-only vendors for making their products a little more accessible to the common man!When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Rel
> For read-only, or even read-mostly, MySQL is blisteringly fast.
I think you mean that when doing lookups of a very small (less than 1%) set of data from a single table with simple queries that mysql understands the b-tree index in myisam or oracle's innodb is as fast as any other database. In the case of myisam maybe a little more, in the case of innodb maybe a little less.
I'm sure you don't mean that when selecting 10% of the data of a single table of the database (thereby unable to do b-tree lookups) and doing table scans instead that it is very fast at all. It might be competitive with postgresql, firebird, and sqllite there, but falls *completely* behind oracle, db2, informix, sqlbase, and now sql server when using partitioning. Or parallelism.
And you probably didn't mean that it was fast when handling complex queries. It's notoriously bad about handling them.
> On Linux, with a disk caching policy of "Never, ever commit anything unless you have to swap something
> from RAM, or are about to umount the file system" and enough RAM to cache the whole table file, MySQL writes
> almost as fast as it reads. OSes with more conservative policies, such as insisting to decache often and
> verifying before releasing the RAM, obviously won't be so fast {but who'll be laughing at who when the power
> comes back on?}.
Wouldn't this be better resolved through a storage adapter with 128 mbytes or more of battery-backed disk cache, and then turning on write-caching - and having your storage system handle it? In this scenario you are very unlikely to corrupt or lose data due to a power outage or crash.
And you had mentioned large files - what if you've got a 10 gbyte file? Doing lots of concurrent writing to it? This won't fit into memory, so now you're back to the writing-at-the-speed-of-a-snail speed.
> What is it with the MySQL bashers around here?
- too much hype
- company leadership that covered up missing *basic* features in the product for years insisting people don't need them anyway
- unsubstantiated claims (blisteringly fast) that end up being gross exaggerations at best
- most non-ansi implementation in the marketplace
- deliberately complex dual-licensing scheme that doesn't comply with GPL
- inability to handle even moderately complex queries
- absolutely bizarre exception handling issues (silent truncations, etc)
MySQL is a success story, but mostly a marketing success story. It started as a sql layer on top of flat files - not intended to be a database management system - just a file management system. And then people applied this tool to database management - without even the most basic of features (views, transactions, etc).
This isn't to say that people can't successfully use it for database management. Of course you can. You can also pull stumps with a ford explorer. It's just that the explorer wasn't really designed for pulling stumps, and a tractor does it *so* much better.
And another big reason is that the perl libraries (ala CPAN) do not require a recompile of perl itself. I cannot count the number of times I go to do something in PHP only to discover that PHP has to be recompiled with the switch to include such-and-such library. Need to work against an Oracle database in PHP? Bring down the production web servers to install a new PHP with OCI support enabled. Need to work against Oracle in Perl? Just install the appropriate perl module, no need to do anything drastic.
You sir, should never program.
Always validate all input provided by the user that is used in any way. If it's in a database you're smart enough to escape it (or use query replacement methods that do it for you). If you're sending mail, you damn-well be sure it's an e-mail address. You have RFCs to guide you on this:
http://www.w3.org/Protocols/rfc822/
A field-name consists of one or more printable characters (excluding colon, space, and control-characters). A field-name MUST be contained on one line. Upper and lower case are not dis-tinguished when comparing field-names.
It defines what characters are valid, and if you are about to pipe whatever data you accept into an e-mail, that's something YOU decided to do.
IT IS YOUR JOB to make sure that what you put beside FROM: (or anything in that parameter) is an e-mail address. It shouldn't have a newline. It shouldn't have escape characters. It should probably contain only a limited regex. Would you put an SQL query someone enters into a database? Then why an e-mail address to sendmail?
On a side note, the only way around this is to have a programming language that tags data as tainted if it came from or was derrived from user input and not allow it for input, and having functions that sanitize data and remove that flag. This is first off slower and second not optimal in many situations.
when you see the word 'Linux', drink!
Oh boy, I can account for this claim completely. I used to co-program with another person on a large website that used MySQL from the start. Him and myself would constantly look for ways of increasing performance and minimising lag, but we never tried using a different database. With a site that massive at the time, we should've been using PostgreSQL at least, or even Oracle or DB2 or similar if we could get the money to buy it. I even went as far as rewriting the entire system with the most optimised PHP code possible, and we minimised database usage and dependence, moving several things to sessions that would occasionally update from the database. We even used partitioning strategies by placing the main culprit of the data usage, the forum's replies table (nothing would get purged, only archived with an archived bit set to 1), on a separate hard drive that was only used for storing backups of the database. Performance shot up for a few days, but it quickly went back to sucking ass.
Sure, with all that, I've come to learn how to exploit MySQL to get its best performance, and how to use PHP to its maximum performance, but we would've been better off using a transactional database for one, and more specifically if we had used PostgreSQL from the start. Those efforts are primarily available here, but since the inital optimisations, I've transferred everything to use ADOdb Lite. I hope to get this transferred to a PostgreSQL database instead, but it won't matter much for the original site in question as I no longer program with him.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
I started off doing web coding in PHP 3 years ago, and was even pleasantly pleased when PHP 4 came out as it was a real, practical improvement over PHP3, especially as regards sessions and form data. Since then, I've learnt Java, ASP, Perl and Cold Fusion and started on Ruby. (and C/ObjC for native development)
Today, after not having done any PHP for about two years, I took a look at the PHP 5 documentation.
I was appalled.
Back when I started learning Perl, many of the apparent idiosyncrasies in PHP made sense such as the $syntax, multiple variable assignation, string concatenation and others. PHP had made a simpler version of Perl (automatic dereferencing, yay!). Then, when I was reading through the docs I noticed that PHP5 was doing its utter best to ape the functionality of Java (OO, exceptions, collections, interfaces, reflection, overloading, overriding etc) with the syntax of C++ (:: for static members, -> for virtual methods) but with the same loosely typed variables (Just ask yourself when looking at code you've never seen exactly what type does that unknown function return) and no namespaces (Perl, Java and C++ all have this in some form or another) and a huge array of functions that has no consistency whatsoever.
So, in essence, we have a language that is a mix of Perl, Java and C++ but with no real innovation of its own, unlike Python or Ruby, both of which are extremely consistent and remain true to themselves. Even lowly Javascript is far more consistent than PHP.
There is no way that I will code or design a large webapp in PHP. I had to debug a fairly complex one recently and it was a nightmare. I think I'll wait another few years and look what PHP6 turns out to be.