XmlHttpRequest is not an official part of JavaScript, and is not covered by any existing standard. Yes, it is supported by all of the major browsers *now*, but as far as I'm aware it was implemented by Microsoft first, and copied by the rest later. (In fact, as far as I'm aware, XmlHttpRequest is still not supporeted in any release version of Opera, unless Opera has released a new version with ~the last month. It was only added to the beta versions fairly recently.)
Unless you can show which W3C (or other) standard applies to XmlHttpRequest? The page you linked to says nothing of standards- only how to use it.
more likely, the case was slightly bent out of shape and would short out certain areas of the motherboard even with the standoffs properly installed. i had one of these in college- the case got whcked out of shape by fedex shipping it home one summer. fortunately all of the components still worked except the motherboard, which i got fedex to pay for, but the case was never useful again. i very nearly fried two motherboards trying to figure out why, though.
that's exactly what they'll do. i use to use win95 in vmware for browser testing various versions of IE (before i figured out how to run multiple copies of IE on one machine) because it was so small compared to any other versions of windows. when IE 6 came out, it would no longer run on win95, which had recently gone into extended support. newer versions of directX wouldn't install either. microsoft announced some time ago that the next version of internet explorer would only come with longhorn- they've since backed off from that statement (by actions at least if not official announcement) but i wouldn't be surprised to see IE 7 be xp/longhorn only- already all the security improvements made to IE6 were all part of xp sp 2, and not available for other versions of windows (that i am aware of anyway.)
also, one more reason that manufacturing larger chips is hard- die yeilds go down drastically even with minor increases in die size. the larger you make your chips, the more faulty chips you are going to have to discard in the qa process.
except that cell phones are only cheap/free if you buy them with a two year agreement to speng $35 or more on your cell phone service.
the cell phone i just got for free with my two year cingular service agreement costs almost $250 to buy without a service agreement, if you can at all.
railroad employees? no, i wouldn't expect them to know how to set up a secure web site. However, I would expect Atlantis Technology Corporation, the company that sells this wireless network authentication and management to comapnies and organizations all accross the state of massachusets (and who, presumably the railroad is paying a lot of money for said service) to not make some basic rookie mistakes in web site security.
If you had RTFA, you would know that the problems he discussed regarding South Station's system had nothing to do with unconfigured access points, but rather very poorly configured web servers, and very poor passwords that were chosen by a real person (i.e. login south, password station) and that the system in question was not set up or run by the transportation authority, but by a third party technology company.
I seem to recall stories of an old aircraft carrier (or destroyer maybe?) that had an eniter machine room with no doors or hatches. they didn't find it until after the ship was decommissioned. can't find a reference, but the story seems to show it's head every time this story of the old netware server pops up, so maybe someone else can provide more details.
i've mostly used alternatives to acrobat on *nix, where there are several. for windows, i've never looked that closely before, but a quick google search turned up a few, such as: http://www.visagesoft.com/products/pdfreader/ index.php http://foxitsoftware.com/pdf/rd_intro.php
(disclaimer: as i said, i just found these in a quick google search, so i have no idea how good they are)
as for speeding up Acrobat, I have acrobat 6.0 on windows at work, and after moving all of the files except for the following out of the plug_ins folder, it is substantially faster. i ended up keeping these: EScript.api, EWH32.api, MakeAccessible.api, reflow.api, Search.api
you're saying that all pdf's suck because of the suckiness of one (albeit the dominant) pdf reader?
(by the way, if you move most of the files out of the plugins folder and into the optional folder, it only takes acrobat about a second or two to load. the reason it takes so long normally is that acrobat loads up a bajillion plugins that no one ever uses. not that i don't blame adobe for that, but acrobat can be made tolerable)
You still didn't answer my original question. Is there any advantage in PHP to use the mysql_* functions rather than the PEAR::DB library? Even if you don't expect to ever have to change the database you are using?
I realize that there are differences in the query languages that no (reasonable) abstraction layer can accomodate, but isn't it still better to have one consistant API to program with?
Even if a reader of this book will never move his current web page off of its MySQL database, what if the next website he works on uses SQLite? or SQL Server? If he learns how to write his web applications using PEAR the first time around, then all he has to learn next time is the differences in query language. If he learns how to use only MySQL specific functions in PHP, then on top of learning the differences between databases, he also has to learn an entirely new client library.
a lot of people's experiences come from a while back (e.g. grandparent), and have prompted them to not try it again as it has developed.
well, as i said in my last post, my past experiences with mysql are only a small part of the reason that i don't use mysql today. the biggest reason i don't currently use mysql is that postgresql provides more features that i use, and it's been a long time since i worked on a project where database speed was the primary concern. if i were to work on such a project again, i would be happy to look at mysql again, but lacking that there's not really any compelling reason to consider mysql again and give up stored procedures, true sequences, etc.
the other primary reason that i don't use mysql, which i mentioned, and which i think the poster you responded to meant by 'doing something he doesn't expect' is that the mysql developers have said and done a lot of things over the years which cause me and many others to wonder how much they really know about good database principles. and i would hesitate to trust a database written by people to don't really seem to understand the concepts behind data integrity.
and that's why you see comments like this on a regular basis. it's often based on the impressions that have been made by the developers rather than any specific behavior of mysql itself.
but anyway, an example of mysql doing something you wouldn't expect:
the lest time i used mysql, when you would insert into a column whose primary key is an auto-increment integer, the insert returns the next integer in sequence, whether the insert succeeded or failed. so rather than checking the return value of the insert to see if the query succeeded (and using the value in your application if it did) you have to do a select with that value to see whether there is actually a row present with that id. that is an example of mysql doing something that you wouldn't expect. and that behavior existed for at least two years before it was changed (if it ever was- i have no idea how long that behavior existed before i started using mysql, and whether it was ever fixed after i stopped)
i admitted at the end of the post that the statement in question was meant in jest. regardless of my inflammatory statement, there are many reasons that you may want to change what database you are deploying your application on someday, and when that day comes, you will be awfully sorry if you wrote all of your database code using database specific libraries (e.g. mysql_query(), etc.) rather than a database independent api (e.g. PEAR).
for 99+% of database developers, there is no reason whatsoever to not use a database abstraction layer over a database specific library. and if you are using mysql, or any other open source database for that matter, there's a very good chance you are not in the other 1%.
that being said, i worked in the critical systems team (roughly equal to systems administration) of a company that served 6 billion requests per month off of 16 mysql databases hosted on big beefy sun enterprise boxes. i don't recall exactly, but i believe we were using 3.23 or something around there. we used mysql because oracle wasn't fast enough to handle our traffic, so i do know a bit of what i'm talking about when it comes to running mysql databases under load.
seriously, what is up lately that the people submitting articles can't even bother to write their own summary? i can't even think of how many articles on slashdot in the last two weeks have been just a copy/paste of the first paragraph of the page they were linking to.
Not that this is a new phonomenon or anything, but it seems to have gotten way out of hand lately.
but the point of the LSB was that vendors would only have to do one certification, rather than certify against every distro. if they still have to certify against multiple distributions, it doesn't gain the community much, because app makers wll go back to just certifying against redhat like they used to.
i used mysql at work for some time from 1998-2001. at one job we had about 12-16 mysql servers, and every week, at least one of them would hang until we truncated that data files and restarted the server process. not really a big deal to us, as we used the mysql servers for pure speed- all of the data in the mysql databases was tracking data that was aggreagated into two oracle databases on sun e5000's. (the mysql db's were also on suns, but smaller)
i worked at another job where we were using mysql to back an in house cms system, and the data corruption there was less frequent but more problematic. all of the data that went through the system was also archived in rcs, so we never lost any data, but it was still a pain restoring it.
i haven't used mysql since then, so i don't know what it is like currently, but the attitude of the mysql developers was never very reassuring to me either.(*) it's been a long time since i've worked on a project where database speed was my primary concern, so when i can choose my database, i usually choose postgresql. when i can't, it usually seems to be oracle or ms sql server. if i had to work on another project like i did in '99 where speed was my primary concern, i would take another look at mysql- that was why that company used it after all. for all the problems they had with it, nothing else was nearly fast enough.
(*) given the rather famous rant about why foreign keys are a bad thing and you should never use them, as well as some of the other statements they've made over the years about transactions, atomicity, etc. i have a hard time trusting my data to an application written by somebody with their attitude. that is the main reason i say that while i am sure that the mysql of today is nothing like the mysql i used years ago, i still have no intention of trying it again.
so, now that PHP actually has a complete, functional, and, most importantly, built in database abstraction layer, why are they still teaching people to use mysql_connect/query/etc?
shouldn't everyone be using PEAR::DB by now?
bad news when you decide you want to change your database because mysql can't handle the load without munging your data anymore....
(ok, so the jab at mysql was flamebait, but the rest is a serious question....)
i think it's mainly tradition. mysql was fast, stable, and usable for basic sites long before postgresql. mysql gained a lot of mindshare early on, when they were the only free game in town (as far as most people knew anyway). while postgresql was focused on correctness first, and speed and ease of use only later, mysql was fast and simple to get working almost from the start, and most people didn't know or care why they wanted ACID in a database. now, some six years later, postgresql is mostly a match for mysql in speed, and mysql has added a lot of the 'real' database features that they were criticized for not having early on (although some of us will still not forget their attitude towards implementing them). there's not nearly as much reason to choose one over the other anymore as there used to be, but mysql had the advantage of early mindshare, so all of the websites talk about LAMP, and all of the books talk about "how to do X with mysql".
personally i would never use mysql for data that i didn't want to risk losing, although i have no doubt that it has improved substantially since the last time i had the pleasure of using it. but that's just me.
So unless I need my results very soon after posing the problem, I'm better off spending $500 bucks on a PC and running my problem for 20 days than I am buying 500 CPU-hours from Sun and getting the answer back very quickly.
or maybe you are doing a complex mathematical problem that needs to store lots of intermediate steps in memory. even if you don't care about how long it takes to run, there are some applications that will never run on cheap p3's even if you give them until the end of time.
I agree. I stopped reading when I got to the little summary at the beginning which said they would like the see the firewall in MacOS X enabled by default and antivirus software bundled with all of the options.
MS did have integrated antivirus software once upon a time. I believe it was called Dr. Watson.
It sucked. Couldn't find a thing...
I used it for a year before the network administrator at my high school told me i had brought in a floppy with the monkey.b virus on it and i should check my home computer.
I agree. While I was very happy when I first heard that Microsoft was going to be tried for anti-competitive practices, it became very quickly apparent to me that they were going about completely the wrong way.
Rather than focusing on the software bundling issue, they *should* have been focusing on all of the restrictions that MS was putting on system resalers regarding what they could and could not do.
I think you miss the point of the LSB. LSB is not a package format- there is not such thing as an "LSB package", and deb, ebuild, rpm, etc. have nothing to do with the LSB.
LSB defines a set of libraries and applications that will be present on all LSB compatible distributions/installations. It specifies things like kernel version, libc version, etc. so that a commercial application provider can say that "This application is certified to work with LSB 1.x" instead of "This application is certified to work on redhat 7.2, and may work on debian 2.2, suse 8.0 and possibly other installiations that have kernel 2.4.x, glibc 2.y, and foobar 3.0"
What they are talking about doing now is adding optional components to the LSB. That way an application provider can say for example "This product is certified with LSB2.x + LSB Webserver 1.y" without having to add a web server as part of the LSB and thus requiring it to be installed on non-server computers. Likewise the current LSB defines few (if any) X toolkits, libraries, applications, etc. so in order to say that a commercial desktop application will run on any LSB certified platform, providers would have to statically link a lot of libraries that are already present on most desktop linux machines because the LSB doesn't include them. Also, as the article points out, there is a lot of interest in having Java be part of the standard, but so far they have not made it required because of the licensing issues. This way, Java installations could be standardized but made part of a separate module so that they would not be required for all LSB compliant installations.
However, while having optional modules for the standard doesn't seem like a bad thing to me, the idea of having the distibution providers doing the certification seems like a mistake.
Slashdot Mirror
XmlHttpRequest is not an official part of JavaScript, and is not covered by any existing standard. Yes, it is supported by all of the major browsers *now*, but as far as I'm aware it was implemented by Microsoft first, and copied by the rest later. (In fact, as far as I'm aware, XmlHttpRequest is still not supporeted in any release version of Opera, unless Opera has released a new version with ~the last month. It was only added to the beta versions fairly recently.)
Unless you can show which W3C (or other) standard applies to XmlHttpRequest? The page you linked to says nothing of standards- only how to use it.
more likely, the case was slightly bent out of shape and would short out certain areas of the motherboard even with the standoffs properly installed. i had one of these in college- the case got whcked out of shape by fedex shipping it home one summer. fortunately all of the components still worked except the motherboard, which i got fedex to pay for, but the case was never useful again. i very nearly fried two motherboards trying to figure out why, though.
that's exactly what they'll do. i use to use win95 in vmware for browser testing various versions of IE (before i figured out how to run multiple copies of IE on one machine) because it was so small compared to any other versions of windows. when IE 6 came out, it would no longer run on win95, which had recently gone into extended support. newer versions of directX wouldn't install either. microsoft announced some time ago that the next version of internet explorer would only come with longhorn- they've since backed off from that statement (by actions at least if not official announcement) but i wouldn't be surprised to see IE 7 be xp/longhorn only- already all the security improvements made to IE6 were all part of xp sp 2, and not available for other versions of windows (that i am aware of anyway.)
also, one more reason that manufacturing larger chips is hard- die yeilds go down drastically even with minor increases in die size. the larger you make your chips, the more faulty chips you are going to have to discard in the qa process.
except that cell phones are only cheap/free if you buy them with a two year agreement to speng $35 or more on your cell phone service.
the cell phone i just got for free with my two year cingular service agreement costs almost $250 to buy without a service agreement, if you can at all.
railroad employees? no, i wouldn't expect them to know how to set up a secure web site. However, I would expect Atlantis Technology Corporation, the company that sells this wireless network authentication and management to comapnies and organizations all accross the state of massachusets (and who, presumably the railroad is paying a lot of money for said service) to not make some basic rookie mistakes in web site security.
If you had RTFA, you would know that the problems he discussed regarding South Station's system had nothing to do with unconfigured access points, but rather very poorly configured web servers, and very poor passwords that were chosen by a real person (i.e. login south, password station) and that the system in question was not set up or run by the transportation authority, but by a third party technology company.
I seem to recall stories of an old aircraft carrier (or destroyer maybe?) that had an eniter machine room with no doors or hatches. they didn't find it until after the ship was decommissioned. can't find a reference, but the story seems to show it's head every time this story of the old netware server pops up, so maybe someone else can provide more details.
i've mostly used alternatives to acrobat on *nix, where there are several. for windows, i've never looked that closely before, but a quick google search turned up a few, such as:/ index .php
http://www.visagesoft.com/products/pdfreader
http://foxitsoftware.com/pdf/rd_intro.php
(disclaimer: as i said, i just found these in a quick google search, so i have no idea how good they are)
as for speeding up Acrobat, I have acrobat 6.0 on windows at work, and after moving all of the files except for the following out of the plug_ins folder, it is substantially faster. i ended up keeping these:
EScript.api, EWH32.api, MakeAccessible.api, reflow.api, Search.api
you're saying that all pdf's suck because of the suckiness of one (albeit the dominant) pdf reader?
(by the way, if you move most of the files out of the plugins folder and into the optional folder, it only takes acrobat about a second or two to load. the reason it takes so long normally is that acrobat loads up a bajillion plugins that no one ever uses. not that i don't blame adobe for that, but acrobat can be made tolerable)
Something I just found the other day: Electric Sheep, a screensaver and distributed animated art generator.
You still didn't answer my original question. Is there any advantage in PHP to use the mysql_* functions rather than the PEAR::DB library? Even if you don't expect to ever have to change the database you are using?
I realize that there are differences in the query languages that no (reasonable) abstraction layer can accomodate, but isn't it still better to have one consistant API to program with?
Even if a reader of this book will never move his current web page off of its MySQL database, what if the next website he works on uses SQLite? or SQL Server? If he learns how to write his web applications using PEAR the first time around, then all he has to learn next time is the differences in query language. If he learns how to use only MySQL specific functions in PHP, then on top of learning the differences between databases, he also has to learn an entirely new client library.
a lot of people's experiences come from a while back (e.g. grandparent), and have prompted them to not try it again as it has developed.
well, as i said in my last post, my past experiences with mysql are only a small part of the reason that i don't use mysql today. the biggest reason i don't currently use mysql is that postgresql provides more features that i use, and it's been a long time since i worked on a project where database speed was the primary concern. if i were to work on such a project again, i would be happy to look at mysql again, but lacking that there's not really any compelling reason to consider mysql again and give up stored procedures, true sequences, etc.
the other primary reason that i don't use mysql, which i mentioned, and which i think the poster you responded to meant by 'doing something he doesn't expect' is that the mysql developers have said and done a lot of things over the years which cause me and many others to wonder how much they really know about good database principles. and i would hesitate to trust a database written by people to don't really seem to understand the concepts behind data integrity.
and that's why you see comments like this on a regular basis. it's often based on the impressions that have been made by the developers rather than any specific behavior of mysql itself.
but anyway, an example of mysql doing something you wouldn't expect:
the lest time i used mysql, when you would insert into a column whose primary key is an auto-increment integer, the insert returns the next integer in sequence, whether the insert succeeded or failed. so rather than checking the return value of the insert to see if the query succeeded (and using the value in your application if it did) you have to do a select with that value to see whether there is actually a row present with that id. that is an example of mysql doing something that you wouldn't expect. and that behavior existed for at least two years before it was changed (if it ever was- i have no idea how long that behavior existed before i started using mysql, and whether it was ever fixed after i stopped)
The editors do read the linked articles before posting them, right?
;)
probably not, or they might realize when they're about to post it for the third time
i admitted at the end of the post that the statement in question was meant in jest. regardless of my inflammatory statement, there are many reasons that you may want to change what database you are deploying your application on someday, and when that day comes, you will be awfully sorry if you wrote all of your database code using database specific libraries (e.g. mysql_query(), etc.) rather than a database independent api (e.g. PEAR).
for 99+% of database developers, there is no reason whatsoever to not use a database abstraction layer over a database specific library. and if you are using mysql, or any other open source database for that matter, there's a very good chance you are not in the other 1%.
that being said, i worked in the critical systems team (roughly equal to systems administration) of a company that served 6 billion requests per month off of 16 mysql databases hosted on big beefy sun enterprise boxes. i don't recall exactly, but i believe we were using 3.23 or something around there. we used mysql because oracle wasn't fast enough to handle our traffic, so i do know a bit of what i'm talking about when it comes to running mysql databases under load.
seriously, what is up lately that the people submitting articles can't even bother to write their own summary? i can't even think of how many articles on slashdot in the last two weeks have been just a copy/paste of the first paragraph of the page they were linking to.
Not that this is a new phonomenon or anything, but it seems to have gotten way out of hand lately.
but the point of the LSB was that vendors would only have to do one certification, rather than certify against every distro. if they still have to certify against multiple distributions, it doesn't gain the community much, because app makers wll go back to just certifying against redhat like they used to.
i used mysql at work for some time from 1998-2001. at one job we had about 12-16 mysql servers, and every week, at least one of them would hang until we truncated that data files and restarted the server process. not really a big deal to us, as we used the mysql servers for pure speed- all of the data in the mysql databases was tracking data that was aggreagated into two oracle databases on sun e5000's. (the mysql db's were also on suns, but smaller)
i worked at another job where we were using mysql to back an in house cms system, and the data corruption there was less frequent but more problematic. all of the data that went through the system was also archived in rcs, so we never lost any data, but it was still a pain restoring it.
i haven't used mysql since then, so i don't know what it is like currently, but the attitude of the mysql developers was never very reassuring to me either.(*) it's been a long time since i've worked on a project where database speed was my primary concern, so when i can choose my database, i usually choose postgresql. when i can't, it usually seems to be oracle or ms sql server. if i had to work on another project like i did in '99 where speed was my primary concern, i would take another look at mysql- that was why that company used it after all. for all the problems they had with it, nothing else was nearly fast enough.
(*) given the rather famous rant about why foreign keys are a bad thing and you should never use them, as well as some of the other statements they've made over the years about transactions, atomicity, etc. i have a hard time trusting my data to an application written by somebody with their attitude. that is the main reason i say that while i am sure that the mysql of today is nothing like the mysql i used years ago, i still have no intention of trying it again.
so, now that PHP actually has a complete, functional, and, most importantly, built in database abstraction layer, why are they still teaching people to use mysql_connect/query/etc?
shouldn't everyone be using PEAR::DB by now?
bad news when you decide you want to change your database because mysql can't handle the load without munging your data anymore....
(ok, so the jab at mysql was flamebait, but the rest is a serious question....)
funny, i always thought it was called "learn how to change 'max open connections' in your database configuration"....
i think it's mainly tradition. mysql was fast, stable, and usable for basic sites long before postgresql. mysql gained a lot of mindshare early on, when they were the only free game in town (as far as most people knew anyway). while postgresql was focused on correctness first, and speed and ease of use only later, mysql was fast and simple to get working almost from the start, and most people didn't know or care why they wanted ACID in a database. now, some six years later, postgresql is mostly a match for mysql in speed, and mysql has added a lot of the 'real' database features that they were criticized for not having early on (although some of us will still not forget their attitude towards implementing them). there's not nearly as much reason to choose one over the other anymore as there used to be, but mysql had the advantage of early mindshare, so all of the websites talk about LAMP, and all of the books talk about "how to do X with mysql".
personally i would never use mysql for data that i didn't want to risk losing, although i have no doubt that it has improved substantially since the last time i had the pleasure of using it. but that's just me.
So unless I need my results very soon after posing the problem, I'm better off spending $500 bucks on a PC and running my problem for 20 days than I am buying 500 CPU-hours from Sun and getting the answer back very quickly.
or maybe you are doing a complex mathematical problem that needs to store lots of intermediate steps in memory. even if you don't care about how long it takes to run, there are some applications that will never run on cheap p3's even if you give them until the end of time.
that's the market sun is after with this.
I agree. I stopped reading when I got to the little summary at the beginning which said they would like the see the firewall in MacOS X enabled by default and antivirus software bundled with all of the options.
MS did have integrated antivirus software once upon a time. I believe it was called Dr. Watson.
It sucked. Couldn't find a thing...
I used it for a year before the network administrator at my high school told me i had brought in a floppy with the monkey.b virus on it and i should check my home computer.
I agree. While I was very happy when I first heard that Microsoft was going to be tried for anti-competitive practices, it became very quickly apparent to me that they were going about completely the wrong way.
Rather than focusing on the software bundling issue, they *should* have been focusing on all of the restrictions that MS was putting on system resalers regarding what they could and could not do.
I think you miss the point of the LSB. LSB is not a package format- there is not such thing as an "LSB package", and deb, ebuild, rpm, etc. have nothing to do with the LSB.
LSB defines a set of libraries and applications that will be present on all LSB compatible distributions/installations. It specifies things like kernel version, libc version, etc. so that a commercial application provider can say that "This application is certified to work with LSB 1.x" instead of "This application is certified to work on redhat 7.2, and may work on debian 2.2, suse 8.0 and possibly other installiations that have kernel 2.4.x, glibc 2.y, and foobar 3.0"
What they are talking about doing now is adding optional components to the LSB. That way an application provider can say for example "This product is certified with LSB2.x + LSB Webserver 1.y" without having to add a web server as part of the LSB and thus requiring it to be installed on non-server computers. Likewise the current LSB defines few (if any) X toolkits, libraries, applications, etc. so in order to say that a commercial desktop application will run on any LSB certified platform, providers would have to statically link a lot of libraries that are already present on most desktop linux machines because the LSB doesn't include them. Also, as the article points out, there is a lot of interest in having Java be part of the standard, but so far they have not made it required because of the licensing issues. This way, Java installations could be standardized but made part of a separate module so that they would not be required for all LSB compliant installations.
However, while having optional modules for the standard doesn't seem like a bad thing to me, the idea of having the distibution providers doing the certification seems like a mistake.