magic_quotes and register_globals, which are options that can be turned off: register_globals is off by default, and has been that way for a long time. Anyone who turns it back on deserves what they get. It's a dead issue. magic_quotes is headed for the same fate in PHP 6. They seemed like good ideas at the time the web as young; they turned out not to be.
Yes, but if you develop on a server which has magic_quotes on, and you deploy on a server that has it off, your code won't behave as expected. You have to be aware of magic_quotes before writing anything in PHP, if you want to be safe.
Same goes for register_globals; and it's hardly a non-issue as it's enabled just about everywhere in the name of backwards compatibility. In the article I wrote the site that got exploited had a vulnerability exposed by register_globals.
"Only critical errors are reported...unless you specifically turn up the error_reporting level" Configurable logging and reporting is a feature, not a bug.
You bet it's a bug when only critical errors are reported by default. Errors in code aren't shown, and users don't realize that there's a problem in their code until it's being exploited.
"fopen_urls: By default you can include scripts hosted on other websites!" I'll agree, that should probably be off by default. But a developer has to be naive or dim to either use an URL include, or include a variable in the include directive (and thus introduce the possibility of a URL inclusion) without being damn sure what they're doing.
I don't think you can blame the developer for this. If they develop with magic_quotes on, or register_globals off, or error reporting >E_WARNING, they may not realize the variable in the include string is writeable, and they probably wouldn't realize you can include remote documents anyway.
"Input checking is difficult...Do you want htmlentities() or htmlspecialchars()?" Depends on what you want to do, now, doesn't it? Developers have to know what conditions they need their data to adhere to, and PHP gives them a variety of tools to make it fit those conditions. Feature, not a bug.
What about add_slashes() not escaping everything that mysql_escape() does? Or mysql_escape() not escaping everything that mysql_real_escape() does? What about 5 == "5 OR 1=1"? What about the ability to input arrays (and errors which should be shown when dealing with unexpected arrays aren't printed because of the default error reporting level)? These are bad ideas which make sanitizing input difficult.
It's easier to trip up badly in C (by commiting some memory buffer error) or Perl (by writing line noise code that you can't understand a week later) than PHP. But it's no longer fashionable to bash those languages.
I wouldn't use C for the web either, and Perl can be very clear. I agree that PHP gets a worse rep than it deserves; I like PHP, and understand that if bash or C was the language of the web they'd be just as bad, but they're not and PHP is.
PHP would be so much better if they fixed the security holes; one of the reasons it gets such a bad rep is because it lets newcomers make mistakes so easily, I'd like PHP to be recognized as the excellent language it is but these security problems aren't helping.
Apparently what you see as "problems", others see as features.
Some see pointers and no bounds checking as useful features, but that doesn't mean they're a good idea for security.
I've audited quite a lot of PHP, written an article on PHP security from the hackers perspective, and done quite a lot of PHP development, and I've never come across an security problem that you could blame the developers for!
It's always the developer assuming something about PHP or the PHP environment but getting it wrong; you can argue that the developer should know, but there are so many gotchas in PHP, you have to be an expert to be aware of them all. (I've listed some in a previous post on/. , and won't repeat myself here).
This isn't right for any language, but a language which web applications run on?! The most hostile environment to develop for is not the place for a language that makes it so easy to trip up!
The fault, for the vast majority of PHP security problems, is completely Zend's. Zend needs to give security priority over backwards compatibility, and get rid of all of their problems that developers repeatedly trip up on.
Bills: I pay my bills because I get a service/goods in return, if I didn't pay I wouldn't get the service/goods. I don't see what your example has to do with a discussion around a serial killer.
Murder: Most people don't just have "no real interest" in murdering or raping someone, most people find the thought of anyone doing it disgusting and will stop others doing it.
Google "morality", and if you think you don't have a sense of it, as you seem to be suggesting, go see a psychiatrist.
Diplomacy. Avalon Hill's board game Diplomacy is a classic that fits the Internet like a hand in a glove, and that's why there are zillions of e-mail games going on as we speak; not to mention discussion groups, Gopher sites, Web pages, and quite a few utilities. Modern-day Machiavellis will find their electronic home right here (in rec.games.diplomacy).
They got this one right, but I think web 2.0 fits it even better than e-mail. (then again I'm a bit biased)
I've heard this opinion before and I don't really get it. Ethical actions are actions that limit suffering, I don't see how there can be different codes of ethics.
By the way did the Versailles Treaty have anything to do with the US? I know there were other causes of WWII but wasn't that the main one? (My history is genuinely poor, I'm not being rhetorical)
Since when is an "Acer Ferari" laptop a top of the line laptop
Since they got 2GB of RAM, a built in camera, AMD dual core 64 bit processor, 160gb HDD, HD-DVD, etc, etc. You at least have to agree that the specs are top of the line.
Ever noticed how all the evidence seems to point to the Earth revolving around the Sun? Nothing which has that much evidence going for it could possibly be true, it's just too open and shut...
If it turns out he's innocent (conclusively), great! But those books, cleaning out the passenger seat, the bin liners.. Right now it looks more like first degree murder than a heat of the moment accident, which is even more disgusting in someone who's intelligent.
It's irrational, but the fact that I've used his software makes it all the more uncomfortable.
Before I get "innocent until/unless proven guilty"; just because jurors should absolutely reserve judgment until they come to a verdict doesn't mean that we can't speculate on the likely outcome, and right now the outcome looks very likely.
There are apparently around 3 billion base pairs in our genome, each base pair has 4 states it can be in, which is the equivalent of 2 bits, so that's about 6 billion bits of information per sperm, times 5 million (iirc) ~= 3 TB.
On the other hand this is the one form of data transmission for which speed from the start of the transmission to the end is not a priority..
Browser inconsistencies really are the worst thing about JavaScript. If all HTML was XHTML compliant, and there were no differences between browsers, AJAX would be so much simpler. Depending on what you're coding it can often take far less time to write it for one browser than to get it to work on the four common browsers.
It sounds good, but I think migrating for it just a tad extreme given that it will be implemented for Linux pretty quickly. We're talking about neat new features here, it'll re-enforce or make easier backups and redundancy, but it's not a to-die-for solution that will solve all your problems. There's no way I'd drop a fully configured server installation which does what I need for a new filesystem.
By the way it's nice to see dtrace, open source Java, and now ZFS coming out of Sun recently. I almost feel sorry for how little they get out of a lot of their innovations, they remind me of Bell Labs just before they died.
But don't teach them C. Teach them a language that focuses on how to structure programs without bogging them down with memory management, pointers, etc, etc. A firm understanding of OO would also be much more useful and much easier to grasp.
Oh! How I disagree!
It's the low level stuff that is fun to learn. When I was in High School - I was programming in pascal with inline assembler. It was fun. It was _Great_ fun. I always wanted someone to teach me C.
Object Oriented programming don't teach people the nitty gritty details of things - and it's the nitty gritty details that is the most fun to learn. At least it was for me when I was in high school. Learning Java would be like learning Visual Basic - not a lot of fun.
Yes, they thought us Visual Basic in high school. Ugh.
Oh! How I disagree!
It's the really low level stuff that is fun to learn. When I was in High School - I was programming in machine code. It was fun. It was _Great_ fun. I always wanted someone to teach me the quantum physics involved in transistors, transistor logic, and the Quine McClusky method.
C don't teach people the nitty gritty details of things - and it's the nitty gritty details that is the most fun to learn. At least it was for me when I was in high school. Learning C would be like learning assembly - not a lot of fun.
Yes, they thought us assembly in high school. Ugh.
I hope you don't mind me editing your post to make a point. What a geek likes, and learns years ago when he attended high school, has nothing to do with what's applicable. I do find logic gates more fascinating than C, but teaching it to high school kids who will almost certainly never use it is pointless.
Databases can easily be CPU bound with a large number of users working with a relatively small dataset. Ever hear of OLTP or multi-dimensional OLAP?
First, I expect these are the vast minority of cases.
Second, what instructions could be added that would speed this up enough to warrant the extra expense?
Third, if there's a large benefit to be had why hasn't anyone capitalized and created an external processor to do the job?
Web servers serving dynamic content can easily be CPU bound.
With bundles of instructions which could be specialized or rolled into single instructions? Or because of the inefficiencies of scripts which are run and the scripting languages themselves?
And the idea that operations used in CAD apply only to CAD? Wow.
The GGP was arguing that instructions that are specifically helpful to CAD (in the same way that crypto processors are specifically helpful to crypto, and not applicable elsewhere) should be added to processors to increase CAD performance.
If there are any instructions that can be added that will speed up lots of different pieces of software commonly used including, but not limited to, CAD then of course they should be added (and why wouldn't they be added?), but that's not what we're arguing about. We're arguing about adding instructions to speed up only very specific tasks, and I'm arguing that the tasks listed by the GGP are too specific.
But don't teach them C. Teach them a language that focuses on how to structure programs without bogging them down with memory management, pointers, etc, etc. A firm understanding of OO would also be much more useful and much easier to grasp.
There's a reason there are so few resources on teaching C to high school students; it wasn't meant to be taught to high school students.
As a database guy I really don't think processors would make a bit of difference to database speed in the vast majority of cases. Database design is usually what's at fault when you're shown a slow database, followed closely by query design, followed by memory, followed by hard disks, followed by processors. The same sort of thing applies to web servers; the bottleneck is never the processor.
As for CAD, well I think that would be quite a waste. Remember that processor designers only have so many transistors to use, and they have to make the most of them. It would be a waste of die real estate, chip designer time, CAD software writer time, etc, just to get a slight performance boost. I sure wouldn't want to pay for CAD specific instructions when I don't use any CAD tools.
I think general purpose processors should leave as much as possible up to software; optimize the general purpose stuff as much as possible so that everything runs faster, and if a user needs some extra fast processing capability for a specific task they can get an extra processor for that purpose.
You can buy external graphics, crypto, and physics processors; if there was enough demand there would also be external database, web server, and CAD processors.
If you don't think you have the self discipline to allow yourself the flexibility of PHP without making mistakes then no, you shouldn't use it (this isn't an insult; some people prefer rigidity, some don't). There are lots of good languages out there that are more rigid and therefore harder to make mistakes with.
However if you want the flexibility and rapid development times of PHP, and are a good coder who knows what he wants to do and how to do it, I'd fully recommend PHP.
PHP IMHO is a nice toy but nothing I would use in a commercial project.
I agree that PHP has problems that make it easy for non-experts to leave their scripts wide open, and create terrible, kludgey code; but that does not somehow make it impossible to write good code in PHP.
It's a flexible language compared to Java (this has its benefits too of course), and it has a lot of exposure to people who can't program, but that doesn't mean that good code somehow cannot be written in it.
Slashdot Mirror
Same goes for register_globals; and it's hardly a non-issue as it's enabled just about everywhere in the name of backwards compatibility. In the article I wrote the site that got exploited had a vulnerability exposed by register_globals.
You bet it's a bug when only critical errors are reported by default. Errors in code aren't shown, and users don't realize that there's a problem in their code until it's being exploited.
I don't think you can blame the developer for this. If they develop with magic_quotes on, or register_globals off, or error reporting >E_WARNING, they may not realize the variable in the include string is writeable, and they probably wouldn't realize you can include remote documents anyway.
What about add_slashes() not escaping everything that mysql_escape() does? Or mysql_escape() not escaping everything that mysql_real_escape() does? What about 5 == "5 OR 1=1"? What about the ability to input arrays (and errors which should be shown when dealing with unexpected arrays aren't printed because of the default error reporting level)? These are bad ideas which make sanitizing input difficult. I wouldn't use C for the web either, and Perl can be very clear. I agree that PHP gets a worse rep than it deserves; I like PHP, and understand that if bash or C was the language of the web they'd be just as bad, but they're not and PHP is.
PHP would be so much better if they fixed the security holes; one of the reasons it gets such a bad rep is because it lets newcomers make mistakes so easily, I'd like PHP to be recognized as the excellent language it is but these security problems aren't helping.
Some see pointers and no bounds checking as useful features, but that doesn't mean they're a good idea for security.
I've audited quite a lot of PHP, written an article on PHP security from the hackers perspective, and done quite a lot of PHP development, and I've never come across an security problem that you could blame the developers for!
/. , and won't repeat myself here).
It's always the developer assuming something about PHP or the PHP environment but getting it wrong; you can argue that the developer should know, but there are so many gotchas in PHP, you have to be an expert to be aware of them all. (I've listed some in a previous post on
This isn't right for any language, but a language which web applications run on?! The most hostile environment to develop for is not the place for a language that makes it so easy to trip up!
The fault, for the vast majority of PHP security problems, is completely Zend's. Zend needs to give security priority over backwards compatibility, and get rid of all of their problems that developers repeatedly trip up on.
Bills: I pay my bills because I get a service/goods in return, if I didn't pay I wouldn't get the service/goods. I don't see what your example has to do with a discussion around a serial killer.
Murder: Most people don't just have "no real interest" in murdering or raping someone, most people find the thought of anyone doing it disgusting and will stop others doing it.
Google "morality", and if you think you don't have a sense of it, as you seem to be suggesting, go see a psychiatrist.
I've heard this opinion before and I don't really get it. Ethical actions are actions that limit suffering, I don't see how there can be different codes of ethics.
If the only reason you don't commit crimes is because you fear being punished, then you're not the sort of person I would want to meet.
Euthanasia, for example, is an ethical crime.
This message, posted to one of the highest volume sites on the internet, brought to you by InnoDB (one of MySQL's default storage engines).
I'm not American, and history just isn't my forté.
But what if the US had stayed out of WWII?
By the way did the Versailles Treaty have anything to do with the US? I know there were other causes of WWII but wasn't that the main one? (My history is genuinely poor, I'm not being rhetorical)
Ever noticed how all the evidence seems to point to the Earth revolving around the Sun? Nothing which has that much evidence going for it could possibly be true, it's just too open and shut...
If it turns out he's innocent (conclusively), great! But those books, cleaning out the passenger seat, the bin liners.. Right now it looks more like first degree murder than a heat of the moment accident, which is even more disgusting in someone who's intelligent.
It's irrational, but the fact that I've used his software makes it all the more uncomfortable.
Before I get "innocent until/unless proven guilty"; just because jurors should absolutely reserve judgment until they come to a verdict doesn't mean that we can't speculate on the likely outcome, and right now the outcome looks very likely.
There are apparently around 3 billion base pairs in our genome, each base pair has 4 states it can be in, which is the equivalent of 2 bits, so that's about 6 billion bits of information per sperm, times 5 million (iirc) ~= 3 TB.
On the other hand this is the one form of data transmission for which speed from the start of the transmission to the end is not a priority..
Religion isn't the answer because it answers nothing, atheism isn't the answer because it doesn't pretend to answer anything.
Browser inconsistencies really are the worst thing about JavaScript. If all HTML was XHTML compliant, and there were no differences between browsers, AJAX would be so much simpler. Depending on what you're coding it can often take far less time to write it for one browser than to get it to work on the four common browsers.
It sounds good, but I think migrating for it just a tad extreme given that it will be implemented for Linux pretty quickly. We're talking about neat new features here, it'll re-enforce or make easier backups and redundancy, but it's not a to-die-for solution that will solve all your problems. There's no way I'd drop a fully configured server installation which does what I need for a new filesystem.
By the way it's nice to see dtrace, open source Java, and now ZFS coming out of Sun recently. I almost feel sorry for how little they get out of a lot of their innovations, they remind me of Bell Labs just before they died.
The founding fathers of the USA weren't as religious as the powers that be today.
*Rushes out to get a 64-bit processor, to be able to play games with bit-board chess AI faster!*
It's the really low level stuff that is fun to learn. When I was in High School - I was programming in machine code. It was fun. It was _Great_ fun. I always wanted someone to teach me the quantum physics involved in transistors, transistor logic, and the Quine McClusky method.
C don't teach people the nitty gritty details of things - and it's the nitty gritty details that is the most fun to learn. At least it was for me when I was in high school. Learning C would be like learning assembly - not a lot of fun.
Yes, they thought us assembly in high school. Ugh.
I hope you don't mind me editing your post to make a point. What a geek likes, and learns years ago when he attended high school, has nothing to do with what's applicable. I do find logic gates more fascinating than C, but teaching it to high school kids who will almost certainly never use it is pointless.
Second, what instructions could be added that would speed this up enough to warrant the extra expense?
Third, if there's a large benefit to be had why hasn't anyone capitalized and created an external processor to do the job?
With bundles of instructions which could be specialized or rolled into single instructions? Or because of the inefficiencies of scripts which are run and the scripting languages themselves?
The GGP was arguing that instructions that are specifically helpful to CAD (in the same way that crypto processors are specifically helpful to crypto, and not applicable elsewhere) should be added to processors to increase CAD performance.
If there are any instructions that can be added that will speed up lots of different pieces of software commonly used including, but not limited to, CAD then of course they should be added (and why wouldn't they be added?), but that's not what we're arguing about. We're arguing about adding instructions to speed up only very specific tasks, and I'm arguing that the tasks listed by the GGP are too specific.
But don't teach them C. Teach them a language that focuses on how to structure programs without bogging them down with memory management, pointers, etc, etc. A firm understanding of OO would also be much more useful and much easier to grasp.
There's a reason there are so few resources on teaching C to high school students; it wasn't meant to be taught to high school students.
As a database guy I really don't think processors would make a bit of difference to database speed in the vast majority of cases. Database design is usually what's at fault when you're shown a slow database, followed closely by query design, followed by memory, followed by hard disks, followed by processors. The same sort of thing applies to web servers; the bottleneck is never the processor.
As for CAD, well I think that would be quite a waste. Remember that processor designers only have so many transistors to use, and they have to make the most of them. It would be a waste of die real estate, chip designer time, CAD software writer time, etc, just to get a slight performance boost. I sure wouldn't want to pay for CAD specific instructions when I don't use any CAD tools.
I think general purpose processors should leave as much as possible up to software; optimize the general purpose stuff as much as possible so that everything runs faster, and if a user needs some extra fast processing capability for a specific task they can get an extra processor for that purpose.
You can buy external graphics, crypto, and physics processors; if there was enough demand there would also be external database, web server, and CAD processors.
If you don't think you have the self discipline to allow yourself the flexibility of PHP without making mistakes then no, you shouldn't use it (this isn't an insult; some people prefer rigidity, some don't). There are lots of good languages out there that are more rigid and therefore harder to make mistakes with.
However if you want the flexibility and rapid development times of PHP, and are a good coder who knows what he wants to do and how to do it, I'd fully recommend PHP.
It's a flexible language compared to Java (this has its benefits too of course), and it has a lot of exposure to people who can't program, but that doesn't mean that good code somehow cannot be written in it.
Correction: When I said "a" == 4 == true I mean "a" == true, 4 == true, "a" != 4