Also why is it IP addresses for home isps are so outragiously priced when if you co-locate a server you can get a new ip for like 50 cents extra a month
One of them is literally present on only ONE site in the world, and it's in white text on a white background, with a disclaimer "this email address is a spam honeypot, don't send email to it" in text right next to it.
How do you know someone else didn't find it on your website and decide to opt it in for you?
Specially since CC companies have a vest interest in not filing more insurance covers for lost/stolen/abused CC accounts.
Credit card companies do not lose money here and typically do not care. If a card is reported stolen, all reversed charges go back to the merchant(s) involved. The credit card companies and banks profit from the charge back fees in addition to the normal processing fees.
When you read about a company's credit card database getting stolen, do you ever wonder why the credit card companies don't cancel all the cards?
Blaming PHP for not solving problems in 3rd-party libraries is not really fair.
You are correct that PHP's thread safety issues (most likely) lie with third party libraries. However, PHP could fix most of the problems by using mutexes around the unsafe library calls.
you mostly only have to worry about writing it for two flavors of Windows: 95/2000 and XP
There are two lines of Windows. The 9x line includes 95, 98 and ME. The NT line includes NT 4, 2000 and XP. 9x and NT are a completely different operating system. They both implement the Win32 API and thus run (most of) the same applications.
Right now, there are some 25 million Mac users (supposedly) in the US, and there's one (TurboTax) preparation software application available to them.
FreeBSD and Linux also have the option of using the per-child MPM
According to the Apache docs, perchild MPM does not work. Using FastCGI PHP will likely have much better results. PHP has always had problems with thread safety.
It costs me $35 to buy my own domain and a one off payment of about $30 to zoneedit to set up the mail forwarding.
Use a registrar like directNIC that has $15 domains and free email forwarding.
But note that you don't have to have your own domain to use that method. MTAs like qmail offer extension addresses (user-*@example.com). Also check out spamgourmet for a more advanced approach.
Apple has never sold a computer that didn't include a complete, installable operating system CD or CD set. You also got one or more restore CD's.
Well, then perhaps they forgot to put them in the box. Mine only came with the restore CD (and an iLife CD). Should I be calling Apple about my missing CDs?
Sorry but there is NO cross platform toolkit that is going to look native across those plaftforms. Using native elements doesn't make it native, it just makes it less foreign looking.
Correct, but using native widgets is a lot better than using emulated native widgets. Compare a native app on Win32 or OS X to one using Qt. There is a noticable difference in the way the widgets behave.
Unfortunately, Lighthouse Design, the company which ported FrameMaker 2 and 3 to NeXTstep got bought by Sun, so Adobe didn't even have that option of outsourcing the port.
They certainly had the option to use a different company.
We've been hearing that for years. The best C security coders in the world are the OpenBSD team and guess what, they make mistakes. They fail to validate input sometimes. They have had exploitable bugs in their code.
Funny, then why have the qmail and djbdns security guarantees never been claimed? Perhaps because it really is possible to write secure code in C?
I run 4-STABLE on all of my boxes, so this will be a bit different for 5. Create/etc/make.conf. You can look at/etc/defaults/make.conf and in the handbook for more details:
CFLAGS=-O -pipe NOPROFILE=true NO_BIND=true NO_SENDMAIL=t rue
SUPHOST=cvsupXX.freebsd.org SUP_UPDATE=yes SUP =/usr/local/bin/cvsup SUPFLAGS=-g -L2 SUPFILE=/usr/share/examples/cvsup/stable-supf ile PORTSSUPFILE=/usr/share/examples/cvsup/ports- supfi le
Replace SUPHOST with your CVSup mirror. See the handbook for more info. The NO_BIND and NO_SENDMAIL lines keep buildworld from building BIND and Sendmail, respectively, since I use djbdns and qmail.
Once you have setup/etc/make.conf, you can update the source tree by doing this:
# cd/usr/src # make update
That will also update/usr/ports. If you want to just update ports, run make update from/usr/ports.
Once your source tree is up to date, update the system following section 21.4.1 in the handbook. I skip the single user mode part, since I do everything over SSH:
# mergemaster -p # rm -rf/usr/obj/* # make -j4 buildworld # make -j4 buildkernel # make installkernel # make installworld # mergemaster -i # reboot
The order there is important. The kernel should be built after the world is built, since building the world updates the build tools (this is especially important when it has been a long time since you last updated). The kernel should also be installed before the world is installed.
You should almost always update the kernel when you update the world. If you choose not to reboot immediately after installing the new world, you might notice that tools like ps no longer work, since they don't match the kernel.
These is how I do things after several years of experience. Make sure to read and understand the handbook before doing anything. But really, it's not that hard, especially after you do it a few times.
An unrelated but very useful tip: check out the sysutils/portupgrade port.
If you use php for grabbing stuff from the database, you're a goner. You simply won't scale because it has no connection pooling mechanism.
Connection pooling doesn't help if every PHP script hits the database since you will need a connection for every PHP process anyway. PHP allows for persistent connections.
If you are running PHP as an Apache module and end up with too many connections than your database can handle, then that's your fault. Either fix the Apache and database config, or switch to FastCGI (you will still need to configure it properly, but FastCGI greatly decreases the required number of PHP processes). You could have the exact same configuration error with connection pooling.
Speed: they're all "fast enough." All of these scale well enough that for most sites you won't care, and none of them really scale well enough to support something like cnn.com.... If you want something that will scale to absolutely huge levels (like the aforementioned CNN), J2EE is about the only game in town.
That's simply not true. Many sites that deal with lots of traffic (adult sites, for example) use PHP. With a good web server (i.e. Zeus) and FastCGI PHP, you can scale very easily. Simply add more web servers or more PHP servers (FastCGI PHP can run on a different machine than the web server). A good load balancer like the Zeus Load Balancer could also help, especially if you need session affinity.
The bottleneck is often the database, not the web server or the web application. J2EE isn't going to magically solve this, but good design will. For example, if you are using MySQL, you might replicate the database and have all SELECT queries go to the slaves.
Re:Apache 2.x safe to use yet?
on
PHP 5 RC 1 released
·
· Score: 2, Interesting
I remember reading within the PHP docs about how unsafe it was to use the 2.x release branch of Apache with PHP...something to do with thread safety if I recall.
PHP is not thread safe and likely never will be. The core is thread safe, but not all the extensions are guaranteed to be thread safe due to the external libraries they use. Thread safe issues likely won't show up during testing, but will show up in production under heavy load. This is the reason Zeus recommends using FastCGI instead of ISAPI for PHP, and the reason the recently released Zend WinEnabler uses FastCGI.
I strongly recommend using the FastCGI interface to PHP, even under Apache. The FastCGI interface is much faster than mod_php4 under Zeus and will likely faster under Apache too. It has the advantages that you can control resource usage better (no bloated PHP environment in every Apache process), run PHP as a different user than the web server and even run PHP on a different machine than the web server.
FastCGI rocks. It is a shame that many things are written as Apache modules and not FastCGI. The trend of "compiling everything into the web server" is bad engineering.
Slashdot Mirror
Also why is it IP addresses for home isps are so outragiously priced when if you co-locate a server you can get a new ip for like 50 cents extra a month
Simple: because they can.
If there are still some PHP libraries that are not thread-safe (and you need those libraries), just don't run in multi-threaded mode.
Or use FastCGI.
IronPort's business is SPAM prevention.
Actually, they play both sides of the fence.
You, my friend, watch way too many movies.
The sarcasm went right over your head.
One of them is literally present on only ONE site in the world, and it's in white text on a white background, with a disclaimer "this email address is a spam honeypot, don't send email to it" in text right next to it.
How do you know someone else didn't find it on your website and decide to opt it in for you?
Specially since CC companies have a vest interest in not filing more insurance covers for lost/stolen/abused CC accounts.
Credit card companies do not lose money here and typically do not care. If a card is reported stolen, all reversed charges go back to the merchant(s) involved. The credit card companies and banks profit from the charge back fees in addition to the normal processing fees.
When you read about a company's credit card database getting stolen, do you ever wonder why the credit card companies don't cancel all the cards?
Links? References? Explanations?
Array do's and don'ts
Serious question: are there any open source scripting languages that _can_ handle threads?
Python has full thread support.
Blaming PHP for not solving problems in 3rd-party libraries is not really fair.
You are correct that PHP's thread safety issues (most likely) lie with third party libraries. However, PHP could fix most of the problems by using mutexes around the unsafe library calls.
you mostly only have to worry about writing it for two flavors of Windows: 95/2000 and XP
There are two lines of Windows. The 9x line includes 95, 98 and ME. The NT line includes NT 4, 2000 and XP. 9x and NT are a completely different operating system. They both implement the Win32 API and thus run (most of) the same applications.
Right now, there are some 25 million Mac users (supposedly) in the US, and there's one (TurboTax) preparation software application available to them.
There is also TaxCut Premium for Mac.
Looking at the cost of "Tax Cut for the Web" prices on their site it's cheaper to have my taxes done by a local tax firm.
Then it's also cheaper than the stand-alone software. Problem solved.
FreeBSD and Linux also have the option of using the per-child MPM
According to the Apache docs, perchild MPM does not work. Using FastCGI PHP will likely have much better results. PHP has always had problems with thread safety.
It costs me $35 to buy my own domain and a one off payment of about $30 to zoneedit to set up the mail forwarding.
Use a registrar like directNIC that has $15 domains and free email forwarding.
But note that you don't have to have your own domain to use that method. MTAs like qmail offer extension addresses (user-*@example.com). Also check out spamgourmet for a more advanced approach.
Apple has never sold a computer that didn't include a complete, installable operating system CD or CD set. You also got one or more restore CD's.
Well, then perhaps they forgot to put them in the box. Mine only came with the restore CD (and an iLife CD). Should I be calling Apple about my missing CDs?
If it is truly from 1962, IBM 1401 assembly language would be the most likely candidate.
Now that's job security.
Wrong. The developer tools, including the compiler, come with the OS, on the "Xcode Tools" CD.
My PowerBook only came with a restore CD.
Sorry but there is NO cross platform toolkit that is going to look native across those plaftforms. Using native elements doesn't make it native, it just makes it less foreign looking.
Correct, but using native widgets is a lot better than using emulated native widgets. Compare a native app on Win32 or OS X to one using Qt. There is a noticable difference in the way the widgets behave.
Don't guess that their home directory is /home/blah, use the objects given to you and find out
/home.
UNIX apps doing things like that are hosed anyway for portability. For example, on Mac OS X, there is no
Still...they're doing it for the sake of commercial interests, not simply for the sake of exploration and gathering knowledge
There is at least one team doing it for exactly those reasons. Go John Carmack!
Unfortunately, Lighthouse Design, the company which ported FrameMaker 2 and 3 to NeXTstep got bought by Sun, so Adobe didn't even have that option of outsourcing the port.
They certainly had the option to use a different company.
We've been hearing that for years. The best C security coders in the world are the OpenBSD team and guess what, they make mistakes. They fail to validate input sometimes. They have had exploitable bugs in their code.
Funny, then why have the qmail and djbdns security guarantees never been claimed? Perhaps because it really is possible to write secure code in C?
For people who've never done this before (such as myself), this is an intimidating operation; care to walk me through it?
h andbook/cutting-edge.html h andbook/makeworld.html
/etc/make.conf. You can look at /etc/defaults/make.conf and in the handbook for more details:
t rue
P =/usr/local/bin/cvsupf ile- supfi le
/etc/make.conf, you can update the source tree by doing this:
/usr/src
/usr/ports. If you want to just update ports, run make update from /usr/ports.
/usr/obj/*
First, RTFM:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/
http://www.freebsd.org/doc/en_US.ISO8859-1/books/
I run 4-STABLE on all of my boxes, so this will be a bit different for 5. Create
CFLAGS=-O -pipe
NOPROFILE=true
NO_BIND=true
NO_SENDMAIL=
SUPHOST=cvsupXX.freebsd.org
SUP_UPDATE=yes
SU
SUPFLAGS=-g -L2
SUPFILE=/usr/share/examples/cvsup/stable-sup
PORTSSUPFILE=/usr/share/examples/cvsup/ports
Replace SUPHOST with your CVSup mirror. See the handbook for more info. The NO_BIND and NO_SENDMAIL lines keep buildworld from building BIND and Sendmail, respectively, since I use djbdns and qmail.
Once you have setup
# cd
# make update
That will also update
Once your source tree is up to date, update the system following section 21.4.1 in the handbook. I skip the single user mode part, since I do everything over SSH:
# mergemaster -p
# rm -rf
# make -j4 buildworld
# make -j4 buildkernel
# make installkernel
# make installworld
# mergemaster -i
# reboot
The order there is important. The kernel should be built after the world is built, since building the world updates the build tools (this is especially important when it has been a long time since you last updated). The kernel should also be installed before the world is installed.
You should almost always update the kernel when you update the world. If you choose not to reboot immediately after installing the new world, you might notice that tools like ps no longer work, since they don't match the kernel.
These is how I do things after several years of experience. Make sure to read and understand the handbook before doing anything. But really, it's not that hard, especially after you do it a few times.
An unrelated but very useful tip: check out the sysutils/portupgrade port.
If you use php for grabbing stuff from the database, you're a goner. You simply won't scale because it has no connection pooling mechanism.
Connection pooling doesn't help if every PHP script hits the database since you will need a connection for every PHP process anyway. PHP allows for persistent connections.
If you are running PHP as an Apache module and end up with too many connections than your database can handle, then that's your fault. Either fix the Apache and database config, or switch to FastCGI (you will still need to configure it properly, but FastCGI greatly decreases the required number of PHP processes). You could have the exact same configuration error with connection pooling.
Speed: they're all "fast enough." All of these scale well enough that for most sites you won't care, and none of them really scale well enough to support something like cnn.com. ...
If you want something that will scale to absolutely huge levels (like the aforementioned CNN), J2EE is about the only game in town.
That's simply not true. Many sites that deal with lots of traffic (adult sites, for example) use PHP. With a good web server (i.e. Zeus) and FastCGI PHP, you can scale very easily. Simply add more web servers or more PHP servers (FastCGI PHP can run on a different machine than the web server). A good load balancer like the Zeus Load Balancer could also help, especially if you need session affinity.
The bottleneck is often the database, not the web server or the web application. J2EE isn't going to magically solve this, but good design will. For example, if you are using MySQL, you might replicate the database and have all SELECT queries go to the slaves.
I remember reading within the PHP docs about how unsafe it was to use the 2.x release branch of Apache with PHP...something to do with thread safety if I recall.
PHP is not thread safe and likely never will be. The core is thread safe, but not all the extensions are guaranteed to be thread safe due to the external libraries they use. Thread safe issues likely won't show up during testing, but will show up in production under heavy load. This is the reason Zeus recommends using FastCGI instead of ISAPI for PHP, and the reason the recently released Zend WinEnabler uses FastCGI.
I strongly recommend using the FastCGI interface to PHP, even under Apache. The FastCGI interface is much faster than mod_php4 under Zeus and will likely faster under Apache too. It has the advantages that you can control resource usage better (no bloated PHP environment in every Apache process), run PHP as a different user than the web server and even run PHP on a different machine than the web server.
FastCGI rocks. It is a shame that many things are written as Apache modules and not FastCGI. The trend of "compiling everything into the web server" is bad engineering.