Yes, but that bug wasn't of that kind, really: it gave a precise description of the circumstances believed likely to cause the bug. The least they could have done was leave it open and on file. For some reason, PHP developers seem to have an obsession with closing bug reports. They'll close a report simply because nothing has happened on it for some time, whether or not a fix has been produced.
even the stupid TV-License (gosh, I have received tens of "this is the final advice, we are knocking down your door next time").
Something I've been waiting for someone to try for a while. If you've informed them that you don't have a TV (or, conversely, do have a licence), but they continue sending the letters anyway, they may be in breach of the Malicious Communications Act, 1988.
Britons are the biggest binge-drinkers in Europe. Binge-drinking basically means going out on the town to get blind drunk.
That's the generally accepted definition of binge drinking. If you look closer at government publications, however, you'll find they use a different one. See for instance this study which uses the definition "drinking enough to feel drunk at least once per month" to define a binge drinker.
The reason the government sees there being such a binge drinking problem is that they've defined it in such a way that it's actually hard to avoid being a binge drinker without completely abstaining.
Have a back end program that doesn't produce any HTML output. Have it produce a data structure that describes the information to be embedded in the page, along with the name of the template to embed the data into. More complex schemes may be necessary for some apps, but this suffices for most. Serialize this data structure (you could use any appropriate data serialization format, I generally use simple XML schemes)
Write a front end program that takes the user's request parameters and parses them, selects an appropriate back end program and then includes its response via file ('http://whatever') (or cURL if you need to POST data). Then it can either do what I do, which is use a template engine to process that data into an HTML page, or if you're feeling too lazy to do it that way you can use PHP itself as the template engine: just include ("../templates/" . $templatename . ".inc") (after suitably validating $templatename of course). The code in the template is very simple, using PHP only for simple variable substitution and iteration over predefined data structures.
If you only need logical and not physical separation of the front and back ends, you can include a file with the implementation of the data-structure producing logic and call that, which should save the cost of serialization and deserialization.
I'm not a programmer and never will be, so "Code your own!" doesn't work for me. If PHP is really so insecure then what are realistic alternatives?
Right now, they're very few and very far between. You could look through sourceforge projects in the Internet/WWW category with the filter 'excluding programming language PHP' applied.
The problem is that so much stuff was implemented in PHP in the late 90s/early 2000's that just about every hosting service went out and installed it. This led to a positive feedback system where nearly everyone chose to develop for PHP, because that's what nearly every hosting service offers, etc. It's the same kind of situation that led to Windows dominance, only (IMO) without the product actually being anywhere near as good.
Register Globals has been off by default for years.
Yes, but most hosting companies just switch it straight back on again, to stem the tide of complaints from users who downloaded an old script from somewhere but it doesn't work...
This "feature" was used for passing request parameters into the script. So there was a legitimate need for it, it was just implemented in a really bone-headed way, since it allowed the overriding of local variables if you weren't careful. This was fixed in version 5 - unfortunately, this meant breaking backwards compatibility, since most older scripts relied on the old way of passing parameters. So a lot of servers out there (I'm assuming yours is among them) are still stuck using PHP 4.
Strange. I have a server running PHP 5, and have scripts installed on it that depend upon the behaviour you describe..htaccess: phpflag register_globals on
PHP allows some things it really shouldn't.. take includes on a variable for instance [...] I mean really.. what legitimate reason is there for that "feature" in the first place?
1. Define in a config file a variable that specifies the location of your code, e.g.:
In the rest of the code: include ($modulebase . "/file_you_need.inc");
Then, you can upgrade versions of the modules by installing a new version in a new directory, and switching the modulebase reference when you're ready.
2. Code autoloader:
function __autoload($classname) {
global $modulebase;
if (file_exists ($modulebase . "/" . $classname . ".inc"))
include ($modulebase . "/" . $classname . ".inc"); }
For large projects, this is pretty much necessary. The only viable alternative is including all of your code all of the time, which often results in slow performance because PHP is spending too much time parsing your scripts.
One of the things I dislike about PHP and I liked about the WebForms.NET approach is the separation of the interface with the functionality which allowed us to create a real multi tier application. I have not programmed "for real" web applications for some time but as far as I know it is not possible to do that sepparation with PHP.
As somebody who has written a 3-tier web application in PHP for a well-known multinational company, I can assure you that tier separation is not only possible in PHP, it's actually fairly easy. Just don't try forwarding remote session IDs to the middle tier from the front tier and then running them on the same server. It won't work.
after looking what they did with mysql_real_escape_string() and mysql_escape_string() I agree with GP. What kind of programming language is that? what the heck does REAL is supposed to mean?
It's a backwards compatibility hack. When they implement mysql_escape_string, the MySQL C API didn't need a connection object to the server to perform quoting, it just did it locally. Some advanced features were added in later MySQL versions, and a connection to the server is now needed in order to know what character set is in use in order for the quoting to be performed correctly. If you're just using us-ascii/iso-8859-1 like most MySQL developers, you can ignore the difference. If you're using UTF8 or some other charset, you need to make sure you use the "_real_" version.
The whole 'mysql_*' API ought to be deprecated anyway. mysqli is much better.
Do not let it execute inside web pages. X server pages is bad. Take PHP outside of web pages altogether. Good PHP programmers should be using Smarty templates anyways.
One way of looking at PHP is that it is an extremely powerful templating language. That's the job it was designed to do in the first place, anyway. So why not write your back end in a more powerful language and just do a quick front end templating job in PHP that takes those results and slaps them into a web page.
Oh, right, the reason not to is that PHP is just about the only common denominator you'll find at nearly any web hosting company you might choose to go with. I think this is just about the only reason not to though.
(I say, begrudgingly, as a PHP programmer who uses the language only because of this popularity factor)
PHP has nice C/Perl syntax, it has the potential for a good general purpose language.
I don't think so. There is at least one major flaw with its language design (and it's a basic, fundamental flaw that most people don't realise): there is no distinction between strings and identifiers. Try this:
It's an interesting choice: '$' becomes an unary operator that returns a reference to the value of its argument. So why doesn't work? God knows. It should, but it doesn't. Probably the same reason that functionReturningAnObject()->field doesn't work: the language definition is screwed up. $v = "t"; echo $$v; works fine though.
Reference semantics are screwed up as well. Try this:
$a = array (1, 2, 3, 4); foreach ($a as &$b) $b++; foreach ($a as $b) $b++; print_r ($a);
Now, explain to me why it is that the last item in $a is incremented twice, while all the others are only incremented once?
The more features are added to it, the more evidence there is that at its core, PHP is a badly designed language.
P.S The/. security image is the word "toasted". Haha nice!
This comment reflects what seems to be one of the biggest misconceptions in computer security. People seem to be under the impression that vulnrabilities are magically conjured into existance when the bugs are made public.
Well, yes, but the fact is that there is incalculably higher risk from an unpatched, publicised bug (especially if more than a few weeks old) than there is in an unpublicised one. Almost all exploits occur using well known bugs, even if you discount worms.
I really shouldn't be surprised at the PHP team's approach to security any more, but it really does still surprise me from time to time. It's amazing, but the PHP team are worse than Microsoft ever were with security. And they don't even learn from this - they've had this attitude for as long as I can remember (PHP 3 days), and they just aren't getting it. Or rather, if they get it, they just don't care.
Maybe you shouldn't bother with the patches. If you're running any of the well-known PHP software, there's a good change your server has already been compromised by one or more such script kiddies.
I actually persuaded my business partner to authorise a 2-month long project to reimplement all the features we need from phpBB from scratch, rather than use original code, just for this reason. It didn't take much work to convince him that we didn't want the hassle of having to deal with regular0-dayexploit scripts in the wild.
However, I don't understand how a non-colonizing civilization could be so dominant as to actually ban colonization by others.
That's quite a simple scenario, actually. Consider the galaxy, for a moment, from the perspective of the first species to develop the capability of colonizing it. You begin to do so, but after a period of expansion not long enough to engulf the entire galaxy, you realise that among other consequences of your actions, you have annihilated another species that would have become intelligent.
The shock of this news spreads throughout your civilisation, and a consensus emerges that colonisation is evil. A small portion of your civilisation, however, decides that they will gain power by continuing to colonise. A police force is set up to prevent them, and does so.
We now have a civilisation at pretty impressive power: a large empire, spanning perhaps hundreds of thousands of worlds. With those resources at its disposal, it sets about preventing the same mistake happening again. It develops artificially intelligent sentries, that watch for civilisations that have begun colonial attempts, and stops them from proceding out of a small region around their birth stars. These sentries are dispersed throughout the galaxy, and over the kind of timescales where a colonisation program might begin could muster larger forces from surrounding areas (perhaps via self-replication from available resources), large enough to deter any realistic attempt to break free.
Basic probability also suggests that it is extremely unlikely that we are an isolated occurrence.
Sorry, that's a rather naive interpretation of the results.
1. First of all, the range of probabilities where there is exactly one civilization emerging is actually a larger range than all the others (other than zero civilizations); i.e. 1 civilization is a more likely outcome than, say, 10 civilizations. Admittedly, this still makes it a pretty unlikely outcome, but it does mean that it doesn't tell us as much as you claim.
2. Even if that weren't the case, the Weak Anthropic Principle influences the possible outcomes.
Even if the probability of intelligent life arising were extremely low, nobody would be there to make the argument if it didn't happen, therefore we can state that anything higher than a zero probability for a civilization existing must (perhaps over a rather large number of trials, in a multiple-universe existence) result in at least one civilization existing.
Using Bayesian probabilities: P(at least one civilization exists / [all the things we know, including that we exist]) = 1.
Now, the range of parameters where the expected outcomes are 1 or fewer civilizations is rather large.
The problem is, expansion is driven by population pressure. The kind of space travel you're theorizing wouldn't do a damn thing to relieve local population pressure, so it would be more of a sort of species level masturbation, to send out ships to make colonies that are so far away that you'd never be able to engage in any sort of trade or cultural exchange.
I'm not sure what it is, but you seem to be making an incorrect assumption somewhere. The first step would be affordable orbital launches (e.g. $200/kg, which should be achievable). Once this has happened, colonies would be established in LEO, at lagrange points between Earth & moon, and in elliptical orbits that regularly approach both. There would be every opportunity for cheap & easy migration and trade, and such colonies could easily support a higher population than Earth itself can.
Or a Dyson sphere or a Ringworld. Then you don't need to leave the solar system until the Sun runs out... unless aliens attack it, the Sun becomes unstable, a meteor pokes a hole in it and lets all the air out, or something else bad happens.
The advantage of small colonies (e.g. O'Neill cylinders) is that they're redundant: failure of a single colony doesn't wipe humanity out. That leaves the unlikely scenarios of alien attack or unexpected solar death as potential "existential events" to use a term from a paper I read a while back. A single, solar-scale colony is much more sensitive to an individual point of failure.
I don't get the whining about gimp. To me, it looks like someone took the parts of photoshop that don't get "windowed" and "de-windowed" them. I mean what is the difference in gimp's and photoshop's gui? The wrapper/window.
Guess what? Slide that background in photoshop off the the side, and gee, you don't have access to file, edit, etc. but it looks like gimp.
Well, if I slide photoshop's "background" window off to the side, I find it isn't so much a background as a container, and my open documents move with it. If I minimize it, all my open documents are minimized, along with all the toolbars, etc. If I click to bring it to the front, all of its associated windows come with it. This is much more useful than having to manage all those windows independently.
But, frankly, that's the least of my concerns with Gimp. I find the fact that everything is organised into just two menus ("File" and "Xtras") inconvenient. A shallower, broader menu system makes it easier to find any individual item. Photoshop has 9 top level menus, each of which is substantially smaller than either of gimp's 2. Many of Gimp's menus have names that are incomprehensible to anyone but an expert. The handling of selections (particularly what it calls 'floating selections') is frankly bizarre, and difficult in practice to use even for somebody with months of experience using the software (albeit compared to years of using photoshop). Moving layers can be tricky, because layer selections change automatically when you click with the move tool (this is an option in photoshop, but not on by default).
Slashdot Mirror
Yes, but that bug wasn't of that kind, really: it gave a precise description of the circumstances believed likely to cause the bug. The least they could have done was leave it open and on file. For some reason, PHP developers seem to have an obsession with closing bug reports. They'll close a report simply because nothing has happened on it for some time, whether or not a fix has been produced.
even the stupid TV-License (gosh, I have received tens of "this is the final advice, we are knocking down your door next time").
:)
Something I've been waiting for someone to try for a while. If you've informed them that you don't have a TV (or, conversely, do have a licence), but they continue sending the letters anyway, they may be in breach of the Malicious Communications Act, 1988.
It'd be fun trying it, at least.
Britons are the biggest binge-drinkers in Europe. Binge-drinking basically means going out on the town to get blind drunk.
That's the generally accepted definition of binge drinking. If you look closer at government publications, however, you'll find they use a different one. See for instance this study which uses the definition "drinking enough to feel drunk at least once per month" to define a binge drinker.
The reason the government sees there being such a binge drinking problem is that they've defined it in such a way that it's actually hard to avoid being a binge drinker without completely abstaining.
If the interface is the only thing you don't like about Gimp, have you tried Gimpshop?
Not yet. Does it get rid of GTK?
Have a back end program that doesn't produce any HTML output. Have it produce a data structure that describes the information to be embedded in the page, along with the name of the template to embed the data into. More complex schemes may be necessary for some apps, but this suffices for most. Serialize this data structure (you could use any appropriate data serialization format, I generally use simple XML schemes)
Write a front end program that takes the user's request parameters and parses them, selects an appropriate back end program and then includes its response via file ('http://whatever') (or cURL if you need to POST data). Then it can either do what I do, which is use a template engine to process that data into an HTML page, or if you're feeling too lazy to do it that way you can use PHP itself as the template engine: just include ("../templates/" . $templatename . ".inc") (after suitably validating $templatename of course). The code in the template is very simple, using PHP only for simple variable substitution and iteration over predefined data structures.
If you only need logical and not physical separation of the front and back ends, you can include a file with the implementation of the data-structure producing logic and call that, which should save the cost of serialization and deserialization.
I'm not a programmer and never will be, so "Code your own!" doesn't work for me. If PHP is really so insecure then what are realistic alternatives?
Right now, they're very few and very far between. You could look through sourceforge projects in the Internet/WWW category with the filter 'excluding programming language PHP' applied.
The problem is that so much stuff was implemented in PHP in the late 90s/early 2000's that just about every hosting service went out and installed it. This led to a positive feedback system where nearly everyone chose to develop for PHP, because that's what nearly every hosting service offers, etc. It's the same kind of situation that led to Windows dominance, only (IMO) without the product actually being anywhere near as good.
Do we need a month dedicated to every application that has bugs in it? Because I'm pretty sure our sun will have imploded by then.
Suns normally explode. Only IBM Netfinities implode.
Oh, right. You meant... never mind.
If he really wants to make a difference, he should fork PHP and really fix up the language and interpreter to his liking.
Err... he has.
Sometimes I think people don't read the articles.
Then I remember I'm reading slashdot.
Register Globals has been off by default for years.
Yes, but most hosting companies just switch it straight back on again, to stem the tide of complaints from users who downloaded an old script from somewhere but it doesn't work...
This "feature" was used for passing request parameters into the script. So there was a legitimate need for it, it was just implemented in a really bone-headed way, since it allowed the overriding of local variables if you weren't careful. This was fixed in version 5 - unfortunately, this meant breaking backwards compatibility, since most older scripts relied on the old way of passing parameters. So a lot of servers out there (I'm assuming yours is among them) are still stuck using PHP 4.
.htaccess:
Strange. I have a server running PHP 5, and have scripts installed on it that depend upon the behaviour you describe.
phpflag register_globals on
PHP allows some things it really shouldn't.. take includes on a variable for instance [...] I mean really.. what legitimate reason is there for that "feature" in the first place?
1. Define in a config file a variable that specifies the location of your code, e.g.:
config.inc:
$modulebase = "/usr/local/lib/mypackage/2.3.11/modules";
In the rest of the code:
include ($modulebase . "/file_you_need.inc");
Then, you can upgrade versions of the modules by installing a new version in a new directory, and switching the modulebase reference when you're ready.
2. Code autoloader:
function __autoload($classname)
{
global $modulebase;
if (file_exists ($modulebase . "/" . $classname . ".inc"))
include ($modulebase . "/" . $classname . ".inc");
}
For large projects, this is pretty much necessary. The only viable alternative is including all of your code all of the time, which often results in slow performance because PHP is spending too much time parsing your scripts.
One more thing:
.NET approach is the separation of the interface with the functionality which allowed us to create a real multi tier application. I have not programmed "for real" web applications for some time but as far as I know it is not possible to do that sepparation with PHP.
One of the things I dislike about PHP and I liked about the WebForms
As somebody who has written a 3-tier web application in PHP for a well-known multinational company, I can assure you that tier separation is not only possible in PHP, it's actually fairly easy. Just don't try forwarding remote session IDs to the middle tier from the front tier and then running them on the same server. It won't work.
after looking what they did with mysql_real_escape_string() and mysql_escape_string() I agree with GP. What kind of programming language is that? what the heck does REAL is supposed to mean?
It's a backwards compatibility hack. When they implement mysql_escape_string, the MySQL C API didn't need a connection object to the server to perform quoting, it just did it locally. Some advanced features were added in later MySQL versions, and a connection to the server is now needed in order to know what character set is in use in order for the quoting to be performed correctly. If you're just using us-ascii/iso-8859-1 like most MySQL developers, you can ignore the difference. If you're using UTF8 or some other charset, you need to make sure you use the "_real_" version.
The whole 'mysql_*' API ought to be deprecated anyway. mysqli is much better.
Hmmm... The munged PHP code from my post was:
(lack of quotation marks deliberate)
and
(addition of quotation marks also deliberate)
Do not let it execute inside web pages. X server pages is bad. Take PHP outside of web pages altogether. Good PHP programmers should be using Smarty templates anyways.
/. security image is the word "toasted". Haha nice!
One way of looking at PHP is that it is an extremely powerful templating language. That's the job it was designed to do in the first place, anyway. So why not write your back end in a more powerful language and just do a quick front end templating job in PHP that takes those results and slaps them into a web page.
Oh, right, the reason not to is that PHP is just about the only common denominator you'll find at nearly any web hosting company you might choose to go with. I think this is just about the only reason not to though.
(I say, begrudgingly, as a PHP programmer who uses the language only because of this popularity factor)
PHP has nice C/Perl syntax, it has the potential for a good general purpose language.
I don't think so. There is at least one major flaw with its language design (and it's a basic, fundamental flaw that most people don't realise): there is no distinction between strings and identifiers. Try this:
It's an interesting choice: '$' becomes an unary operator that returns a reference to the value of its argument. So why doesn't work? God knows. It should, but it doesn't. Probably the same reason that functionReturningAnObject()->field doesn't work: the language definition is screwed up. $v = "t"; echo $$v; works fine though.
Reference semantics are screwed up as well. Try this:
$a = array (1, 2, 3, 4);
foreach ($a as &$b) $b++;
foreach ($a as $b) $b++;
print_r ($a);
Now, explain to me why it is that the last item in $a is incremented twice, while all the others are only incremented once?
The more features are added to it, the more evidence there is that at its core, PHP is a badly designed language.
P.S The
Did you post AC just so you could make that joke?
This comment reflects what seems to be one of the biggest misconceptions in computer security. People seem to be under the impression that vulnrabilities are magically conjured into existance when the bugs are made public.
Well, yes, but the fact is that there is incalculably higher risk from an unpatched, publicised bug (especially if more than a few weeks old) than there is in an unpublicised one. Almost all exploits occur using well known bugs, even if you discount worms.
I really shouldn't be surprised at the PHP team's approach to security any more, but it really does still surprise me from time to time. It's amazing, but the PHP team are worse than Microsoft ever were with security. And they don't even learn from this - they've had this attitude for as long as I can remember (PHP 3 days), and they just aren't getting it. Or rather, if they get it, they just don't care.
I'm not surprised. Their attitude to bug reports in general is pretty hostile. See, for instance, this report of a segmentation fault bug.
Maybe you shouldn't bother with the patches. If you're running any of the well-known PHP software, there's a good change your server has already been compromised by one or more such script kiddies.
I actually persuaded my business partner to authorise a 2-month long project to reimplement all the features we need from phpBB from scratch, rather than use original code, just for this reason. It didn't take much work to convince him that we didn't want the hassle of having to deal with regular 0-day exploit scripts in the wild.
Yep. This is going to be fun^Wannoying.
Jesus. Is that the same C&VG I used to read in the mid-eighties...?
However, I don't understand how a non-colonizing civilization could be so dominant as to actually ban colonization by others.
That's quite a simple scenario, actually. Consider the galaxy, for a moment, from the perspective of the first species to develop the capability of colonizing it. You begin to do so, but after a period of expansion not long enough to engulf the entire galaxy, you realise that among other consequences of your actions, you have annihilated another species that would have become intelligent.
The shock of this news spreads throughout your civilisation, and a consensus emerges that colonisation is evil. A small portion of your civilisation, however, decides that they will gain power by continuing to colonise. A police force is set up to prevent them, and does so.
We now have a civilisation at pretty impressive power: a large empire, spanning perhaps hundreds of thousands of worlds. With those resources at its disposal, it sets about preventing the same mistake happening again. It develops artificially intelligent sentries, that watch for civilisations that have begun colonial attempts, and stops them from proceding out of a small region around their birth stars. These sentries are dispersed throughout the galaxy, and over the kind of timescales where a colonisation program might begin could muster larger forces from surrounding areas (perhaps via self-replication from available resources), large enough to deter any realistic attempt to break free.
See?
Basic probability also suggests that it is extremely unlikely that we are an isolated occurrence.
Sorry, that's a rather naive interpretation of the results.
1. First of all, the range of probabilities where there is exactly one civilization emerging is actually a larger range than all the others (other than zero civilizations); i.e. 1 civilization is a more likely outcome than, say, 10 civilizations. Admittedly, this still makes it a pretty unlikely outcome, but it does mean that it doesn't tell us as much as you claim.
2. Even if that weren't the case, the Weak Anthropic Principle influences the possible outcomes.
Even if the probability of intelligent life arising were extremely low, nobody would be there to make the argument if it didn't happen, therefore we can state that anything higher than a zero probability for a civilization existing must (perhaps over a rather large number of trials, in a multiple-universe existence) result in at least one civilization existing.
Using Bayesian probabilities:
P(at least one civilization exists / [all the things we know, including that we exist]) = 1.
Now, the range of parameters where the expected outcomes are 1 or fewer civilizations is rather large.
See: Creationism doesn't enter into it at all.
The problem is, expansion is driven by population pressure. The kind of space travel you're theorizing wouldn't do a damn thing to relieve local population pressure, so it would be more of a sort of species level masturbation, to send out ships to make colonies that are so far away that you'd never be able to engage in any sort of trade or cultural exchange.
I'm not sure what it is, but you seem to be making an incorrect assumption somewhere. The first step would be affordable orbital launches (e.g. $200/kg, which should be achievable). Once this has happened, colonies would be established in LEO, at lagrange points between Earth & moon, and in elliptical orbits that regularly approach both. There would be every opportunity for cheap & easy migration and trade, and such colonies could easily support a higher population than Earth itself can.
Or a Dyson sphere or a Ringworld. Then you don't need to leave the solar system until the Sun runs out ... unless aliens attack it, the Sun becomes unstable, a meteor pokes a hole in it and lets all the air out, or something else bad happens.
The advantage of small colonies (e.g. O'Neill cylinders) is that they're redundant: failure of a single colony doesn't wipe humanity out. That leaves the unlikely scenarios of alien attack or unexpected solar death as potential "existential events" to use a term from a paper I read a while back. A single, solar-scale colony is much more sensitive to an individual point of failure.
I don't get the whining about gimp. To me, it looks like someone took the parts of photoshop that don't get "windowed" and "de-windowed" them. I mean what is the difference in gimp's and photoshop's gui? The wrapper/window.
Guess what? Slide that background in photoshop off the the side, and gee, you don't have access to file, edit, etc. but it looks like gimp.
Well, if I slide photoshop's "background" window off to the side, I find it isn't so much a background as a container, and my open documents move with it. If I minimize it, all my open documents are minimized, along with all the toolbars, etc. If I click to bring it to the front, all of its associated windows come with it. This is much more useful than having to manage all those windows independently.
But, frankly, that's the least of my concerns with Gimp. I find the fact that everything is organised into just two menus ("File" and "Xtras") inconvenient. A shallower, broader menu system makes it easier to find any individual item. Photoshop has 9 top level menus, each of which is substantially smaller than either of gimp's 2. Many of Gimp's menus have names that are incomprehensible to anyone but an expert. The handling of selections (particularly what it calls 'floating selections') is frankly bizarre, and difficult in practice to use even for somebody with months of experience using the software (albeit compared to years of using photoshop). Moving layers can be tricky, because layer selections change automatically when you click with the move tool (this is an option in photoshop, but not on by default).