That's probably exactly what the big boss doesn't know, since he's a PHB, and not a techie. What he does know, is it's the most supported distribution. It's definitely the distribution he'll pick to run his DB on.
Don't run insecure software like wu-ftpd and Sendmail and BIND, there are secure and easier alternatives out there. You might be stuck with the existing installation of crappy daemons, but oh well.
It's just a matter of putting those things together. I've attempted to setup a centralized LDAP authentication and configuration, but the current available free implementations just suck miserably, e.g. the PAMLDAP module, and the PAM system itself is a nasty kludge. Anyone tried Caldera's Volution?
This is total BS. 2.4 is production-ready. These are probably the same people who always stay one version behind, thinking their machine will be more stable. 2.4 handles many things better, including higher loads.
Ok, so I may be FUDding. The only way to really compare is to compare real-life application running on both implementations on the same hardware. It sucks, however, that most if not all application servers (not tied to a web ser ver) are Java-based.
It's still Java, with the VM and JIT compiler overhead. What if I do not want to use Java? What choices of application servers do I have in such a case? Furthermore, that application server will probably cost you an arm and a leg more than a bunch of clustered x86s running open software.
As for the connection pooling, it might not even be a requirement for a site. If it's really needed, it will be implemented either in PHP or somewhere else. Also, it's nice to know that the new version of Apache is a hybrid threaded and multi-process, and it even has state threads module from SGI.
That's because they're not trafic shaping their link. They should limit web traffic to a few mbps. Also they should only allow such a number of clients as to always return a reply from the server to the client (i.e., The maximum number of clients is reached, come back later).
Bah, speak for yourself. Java relies on the virtual machine, so that's your bottleneck (as in beer and performance). With proper software (like the new version of Apache still in beta) and tuning, or other threaded servers like aolserver or Xitami and PHP or modperl instead of Java I bet my money _that_ configuration will scale better.
Also, don't confuse the CGI protocol with short-lived CGI binaries. Slashdot uses modperl, whcih is NOT a short-lived process, but Apache is still a forking server in the 1.3.x branch.
Not true, there are state threading libraries that do not require programmer synchronization.
Threads are better than processes where threads are better than processes: depending on the requirements.
One of the reasons why threads are used for scalable software is threads are lighter, either on Windows or *nix. No matter how sofisticated your process management is, threads are still lighter for solving some problems. It should be obvious. One of the other reasons for using threads is shared memory space which simplifies programming depending on the problem at hand.
Create a few dozen thousand processes on a *nix server each handling a TCP/IP connection, and see how well the kernel will manage them. If you don't run out of resources for that may processes that is. Have a nice meltdown.
Create a few processes on a *nix server using a few threads each, each thread handling many connections per second, and compare to the previous model.
Real programmers use the best tool for the job instead of bashing one or another equally usable approach:).
Gee, thanks for offending me as a systems administrator, thanks! Here's what djb has to say about this known *nix problem, which I think is very sound:
"My suspicion is that having lots of executables laying around increases run time / memory usage as well because the system has to deal with that many more processes getting created."
Yes, but it certainly modularizes the system, and catching errors is easier since you know which process to look at (same language or not). And the kernel overhead might not even be that important for the software you're writing. For example, you might be blocked by the slow disk or serial I/O, where kernel overhead is not a factor with many processes, but flexibility is desired.
However, the cost of context switch, though very high for an OS, is not high for some installations. Depends on application. Your disks might as well be the bottlenecks. Profiling is necessary in any case.
There are if the performance doesn't satisfy your requirements. Taking output of a C program and piping it into AWK is a common practice. Piping output of several programs together is also common. If output is long, it can take forever even on fast machines.
Slashdot Mirror
You could try Erlang as the functional language, industrial strength stuff that's fun. www.erlang.org.
That's probably exactly what the big boss doesn't know, since he's a PHB, and not a techie. What he does know, is it's the most supported distribution. It's definitely the distribution he'll pick to run his DB on.
Don't run insecure software like wu-ftpd and Sendmail and BIND, there are secure and easier alternatives out there. You might be stuck with the existing installation of crappy daemons, but oh well.
Wu-ftpd is a known insecure monster.
It's just a matter of putting those things together. I've attempted to setup a centralized LDAP authentication and configuration, but the current available free implementations just suck miserably, e.g. the PAMLDAP module, and the PAM system itself is a nasty kludge. Anyone tried Caldera's Volution?
Couldn't hold back your distribution zealotry, eh? Choose the right tool for the job.
When a big boss makes a decision what distribution or *nix vendor to go with, he'll look at support options first.
This is total BS. 2.4 is production-ready. These are probably the same people who always stay one version behind, thinking their machine will be more stable. 2.4 handles many things better, including higher loads.
Tomcat is still Java.
Ok, so I may be FUDding. The only way to really compare is to compare real-life application running on both implementations on the same hardware. It sucks, however, that most if not all application servers (not tied to a web ser ver) are Java-based.
Sure, but I feel Java VM still has a higher overhead, as in the case of Perl and PHP they lack a VM, and are straight interpreted languages.
What if I do not want to use Java at _all_. Never! Ever! What application servers can I choose from? Not that many, eh?
It's still Java, with the VM and JIT compiler overhead. What if I do not want to use Java? What choices of application servers do I have in such a case? Furthermore, that application server will probably cost you an arm and a leg more than a bunch of clustered x86s running open software.
As for the connection pooling, it might not even be a requirement for a site. If it's really needed, it will be implemented either in PHP or somewhere else. Also, it's nice to know that the new version of Apache is a hybrid threaded and multi-process, and it even has state threads module from SGI.
That's because they're not trafic shaping their link. They should limit web traffic to a few mbps. Also they should only allow such a number of clients as to always return a reply from the server to the client (i.e., The maximum number of clients is reached, come back later).
Your ISP needed to learn traffic shaping.
Bah, speak for yourself. Java relies on the virtual machine, so that's your bottleneck (as in beer and performance). With proper software (like the new version of Apache still in beta) and tuning, or other threaded servers like aolserver or Xitami and PHP or modperl instead of Java I bet my money _that_ configuration will scale better.
Also, don't confuse the CGI protocol with short-lived CGI binaries. Slashdot uses modperl, whcih is NOT a short-lived process, but Apache is still a forking server in the 1.3.x branch.
Yes, Linux developement needs better QA akin to BSDs.
It won't work unless we agree on a standard.
Not true, there are state threading libraries that do not require programmer synchronization.
:).
Threads are better than processes where threads are better than processes: depending on the requirements.
One of the reasons why threads are used for scalable software is threads are lighter, either on Windows or *nix. No matter how sofisticated your process management is, threads are still lighter for solving some problems. It should be obvious. One of the other reasons for using threads is shared memory space which simplifies programming depending on the problem at hand.
Create a few dozen thousand processes on a *nix server each handling a TCP/IP connection, and see how well the kernel will manage them. If you don't run out of resources for that may processes that is. Have a nice meltdown.
Create a few processes on a *nix server using a few threads each, each thread handling many connections per second, and compare to the previous model.
Real programmers use the best tool for the job instead of bashing one or another equally usable approach
DJB has a solution: http://cr.yp.to/unix.html
The alternative is /package /doc and /command from DJB:
Unix
Gee, thanks for offending me as a systems administrator, thanks! Here's what djb has to say about this known *nix problem, which I think is very sound:
compatibility
look under FS layout
"My suspicion is that having lots of executables laying around increases run time / memory usage as well because the system has to deal with that many more processes getting created."
Yes, but it certainly modularizes the system, and catching errors is easier since you know which process to look at (same language or not). And the kernel overhead might not even be that important for the software you're writing. For example, you might be blocked by the slow disk or serial I/O, where kernel overhead is not a factor with many processes, but flexibility is desired.
However, the cost of context switch, though very high for an OS, is not high for some installations. Depends on application. Your disks might as well be the bottlenecks. Profiling is necessary in any case.
There are if the performance doesn't satisfy your requirements. Taking output of a C program and piping it into AWK is a common practice. Piping output of several programs together is also common. If output is long, it can take forever even on fast machines.
Don't confuse economy with the planet. How does overconsumption and waste help the planet?
How about a gift for the planet? The 23d is the "Buy Nothing Day"
There's an OpenLDAP feature already in the works. And if you search their mailing lists, it looks like someone even got it to work over MSSQL!