I beleive it is intelligent enough to do it on a realtime basis, so you just get several setuid()/setgid() calls.
Umm, no. Think about it for a minute. If a process can change it's euid/egid to anything, then that means uid/gid is root, meaning the process is effectively root. Doing this would mean you give every CGI root access.
This is what makes this type of feature so difficult: there is no way for a master process to change the uid/gid of child processes. Once a child (that is root) changes to a uid/gid, it is stuck for life.
I think the main process simply passes the socket descriptor for the new connection to the virtual host process. Passing descriptors isn't terribly efficient, but it only happens on connection, and certainly more efficient than piping data the way you describe. I'm pretty sure the Apache 2.0 design is efficient and scalable.
Apache 1.3 doesn't pass descriptors between processes. The main process runs as root, binds to the appropriate addresses and listens for connections, then forks off child processes, which all listen or accept on those descriptors (possibly using a mutex to avoid the thundering herd problem).
There isn't any real efficiency problem with passing descriptors (unless some OS's do things weirdly). The issue is that there isn't a portable way to do it.
> Which means that php would have to be running as a external executable, which means performance drops.
"Drops" doesn't matter, the important question is, "drops by how much?" For sufficiently small values of 'drop', the security increase would be well worth the tradeoff.
Drops like a rock. While I can't give exact numbers, I can say it is quite noticable.
We use Zeus for our hosting servers (Apache won't cut it for high traffic) and have it run all CGI scripts (PHP, Perl, etc.) as CGI's that run as the uid/gid of the customer. On dual CPU 1ghz+ machines with 1gb+ RAM, there is a noticable difference when running a lot of scripts. The same small number of scripts (with 500+ requests/sec most are static) cause the same load under Apache.
While it would be great to be able to run PHP under FastCGI, as the performance increase would be great (even better than mod_php4 under Apache), we have to keep it secure for our customers.
Anyone want to modify FastCGI PHP to have process pools for different users? It wouldn't be fun at all.
That's great it displays text backwards and all, but mirrors don't reverse the order text. Make yourself a nice big "R" and hold it in front of a mirror. See the difference?
If you use a mirror to read this google mirror you are going to see the letters in the right order, but they are all going to be backwards!
No, you shouldn't. Maildir solves a problem that doesn't need solving, and it is much, much slower than just about any other mailbox format.
Really? How do you safely modify or delete a message from an mbox file? You make a new file and copy the existing one while changing the data that you need changed and then atomically replace the original file. This means you use double the space of the mbox file and take the time to rewrite the entire file. Or, you modify the original mbox file and hope the system doesn't crash while doing so or you risk corrupting the entire thing. And you have to deal with locking in both cases. How is this better than Maildir?
As for being slow, there are benchmarks to prove you wrong (on courier-mta.org).
Check out MenuetOS, "a fully 32 bit assembly written, graphical OS for asm programming, distributed under General Public License". My friend joked that it ran faster under VMware than Windows does natively.
Actually, remapping the keys for use in the normal calculator modes is not a very simple thing to do on the TI calcs. You'd have to register an interrupt handler, and I think the only free memory the calc won't shuffle around is the memory used for the graphics screen. So, while you had the buttons remapped, you couldn't graph.
Right, the 82 and 85 did not have assembly support built in, so interrupt handlers are more trouble. Though quite possible. One of the shells with interrupt support comes with a demo that leaves a grayscale background while in the TI-OS.
However, I was talking about the TI-86, which does have assembly support and has a lot of built in hooks (such as the [sqrt] programs). I did a lot of programming in assembly for that calculator and if you look on ticalc.org, you will find a lot of demos that show you how to do things like that in the TI-OS. A good one to look at is Kirk Meyer's April Fools program. It completely rearranges the keyboard. A good joke to play on someone:)
The hooks for the 86 let you do a lot of stuff. You can remap the keyboard, modify system menus, modify the parser, change output, hook into the grapher, run programs at startup, etc. Pretty much anything you want to do is possible if you're willing to do some digging in the ROM. The hardest part is keeping the TI-OS from crashing when you modify things that you shouldn't.
If you're interested, take a look at this set of hook demos by Clem Vasseur. It's a good example of what can be done and if you actually want to write a hook, then most of the hard work is done for you:
The TI-83 line has built in assembly support, but it is not as good as the 86's, and those calculators suck anyway, so do not consider buying them. The 86 is the best calc overall, especially if you want to have fun programming. The 89 and 92 are ok, have more RAM and a faster CPU (68k instead of z80), but aren't as "clean". The 86 lets you do cool grayscale and has a lot of free RAM to play with. The 83 line can't really do grayscale, don't have much RAM and the screen is smaller (96x64 vs 128x64). The 86 is a fun device to progam.
While TI graphing calculators don't have the hex buttons where you want them, they are very programmable. The TI-86 is reasonably priced and very programmable. You could write yourself a simple conversion app with remapped buttons in TI-BASIC, or go all out and integrate it into the TI-OS using an assembly language program. There are many sites with resources to help you and assembly language mailing lists to get help on. You can do so many cool things with these calculators. Remapping the keys and writing a simple conversion app would be simple.
Damn all you insensitive people with window offices. I work in the basement. I have noticed that the flat pannel monitor I use does a good job of cutting down on the glare from the florecent bulbs. Which brings me to my point. Roomer has it(according to the best buy salesman) that a flat screen TV cuts glare by 60-80%. I would imagine the same would hold true to a flatscreen monitor or flat pannel monitor. I too have to work in a basement with only a sliver of a window to provide natural light. The only light I use in the room is an Eclipse Light. These things absolutely rock. They eliminate glare completely and light up the work area perfectly. And they look cool too (although the older ones were cool looking IMO).
Qmail is licensed in such a way as to rule out forking.
Wrong. qmail is not licensed at all (it is "no license" software). Thus you only have the right to use it, not distribute it. The right to use it inherently includes the right to create and distribute patches: http://cr.yp.to/softwarelaw.html
Maybe this is why MySQL isn't as popular for database(for things other then a website)?
If you are a real DBA, then having to use a SQL console or command line tools to administrate a database shouldn't be a problem. If you need to point and click to make a backup or create tables because SQL is too hard, then there is no way you can be a DBA. Besides, there is a good web based GUI, phpMyAdmin, that lets you do most things without knowing everything about SQL. There are also GUI interfaces to MySQL.
Also, PHP more popular then ASP? Possibly. But name anyone who makes money running a huge website (Slashdot excluded, they don't make money) with MySQL. There may be some, but anyone who is doing serious business isn't going to be using MySQL.
That's complete FUD. Say, do you work for Microsoft or Oracle? I can say first hand that directNIC.com uses MySQL for everything. They are a very popular domain registrar (sold over half a million domains) and are certainly making money. Many other companies use MySQL and not just for running websites. You should rethink your myths.
Fantastic is such a subjective word. Let's just say they are good.
Apache is obviously not fantastic (see my previous posts for why I think that), but it works well for many people. PHP is a good and I personally really enjoy using it, but I certainly wouldn't call it fantastic, mainly due to its quirks and because the developers refuse to fix certain bugs. MySQL is fantastic. It is easy to use and does what it is designed to do very well.
OK, I'm not a Linux man: but I didn't think Linux actually supported proper asynchronous I/O. And the acryonym, for better or for worse, is still LAMP and not FAMP or SAMP (or even SAOP). (WISA, anyone?:-) ) Sure, you can pass a shed-load of sockets into a select() call but I can't see select()'s efficiency being even close to linear in set size.
Linux does not support the POSIX AIO interface with a standard kernel (SGI has an implementation available). The supported Linux method is realtime signals. While there is probably a good reason that they chose this non standard, Linux specific method (besides the "because we can"), I haven't seen anything documenting the reasoning.
Another method,/dev/epoll, is somewhat similar to Solaris'/dev/poll. It is more efficient and has (IMHO) a cleaner interface than the realtime signals. Hopefully this patch will make it into the mainstream kernel.
And, yes, both select() and poll() both have scalability limits somewhere after a few thousand descriptors. However, a non blocking server using these will still be much more scalable than a multiprocess blocking server such as Apache. The overhead of that many processes will kill you.
Do they use non blocking I/O to serve static content? Even when serving dynamic content, the majority of the requests will be for static content. Therefore, to get the best performance, non blocking I/O must be used. Multithreaded servers have an inherent performance limit. On many UNIX systems, threads are as heavyweight as processes.
When will you stop bitching and join the Apache devel team to help make it secure? When will you submit a non-blocking I/O patch to the Apache codebase?
Apache can't be made secure for the same reasons that BIND and Sendmail can't be made secure. It needs to be completely rewritten using secure coding practices. You can't just keep fixing security bugs and hope you found them all.
If you knew anything about Apache's design, then you would know that it's impossible to just add non blocking I/O. The entire server would have to be redesigned. If you read the Apache development list, then you will see that this is never going to happen. The developers don't care. They seem convinced that it is too much work and get upset when anyone mentions the idea of non blocking I/O. There are more than technical issues that need to be solved before Apache can become a better server.
If you don't like the direction they are going, either don't use it or join the devel team. There's no need to bitch and moan about it like it intimately affects your life.
So I'm no longer allowed to give my opinion? I thought that was the purpose of this comment forum.
Apache is NOT the fastest out there...but it is the most configurable (PHP, Perl, etc) and the best all-around webserver there is. Many of us think that the Apache team has done great work and we apprieciate every minute of it.
Yes, that's exactly my point. It's the best we have and no one seems to care that it could be ten times better. And no, it's not just a matter of a few patches. Apache's design is fundamentally flawed.
Great. So the Apache group has once again proven that they can deliver both a slow and insecure web server. How many more security holes will Apache have before it is "secure"? And when will Apache deliver truly high performance by having a non blocking I/O model?
What are our choices for web servers on UNIX platforms? Unfortunately, not many good ones. It looks like if you want speed, fast dynamic content and lots of configurability then Zeus Web Server is the only real option. The downside is that it's not open source and has a hefty price tag (although it is well worth it).
Boa is a nice, simple, fast web server that supports dynamic content through CGI's (so not much performance). publicfile'shttpd is about the ultimate small, simple, fast and secure web server that supports only static content. If you must have a secure web server, this it (for example, defcon.org uses it). While it is a blocking server, it's small size (two data pages) should lead to performance comparable to that of larger, non blocking servers.
Why isn't there a fast (non blocking) web server that supports fast dynamic content such as PHP, either built in (yuck) or through an API like FastCGI, available for UNIX platforms?
Have you tried Quanta? It rocks. On topic, I also use and endorse HomeSite for Win32, it's pretty slick.
I tried Quanta about nine months ago, but the fonts sucked and made it unusable. I set the colors exactly the same as on Windows, and used the same TTF fonts from Windows (which for Courier New, is free from Microsoft). In KDE, there is way too much spacing between lines, and you can't make the fonts bold in the color coding settings like you can in HomeSite (at least, it doesn't work). Also, the editor is missing a lot of important features that HomeSite includes, like the visible margin and gutter with line numbers.
Unfortunately, it's just not a replacement for HomeSite yet. I took screenshots of the editors in Windows and KDE to illustrate the difference. If anyone can explain how to make the fonts look exactly the same in KDE, then I might try KDE again. For me, this a huge usability problem that keeps me in Windows for my workstation desktop.
For anything web related (HTML, CSS, PHP) I use HomeSite. It works. Great editor, nice syntax highlighting, lots of nice features. I haven't found anything even remotely comparable for Linux, unfortunately. For C/C++, C++Builder is excellent. The syntax highlighting works well and the editor is amazingly fast. Works on files of literally any size with no slowdowns.
Common, have you tried to tune Apache?
Process-per-connection not a problem - you just have to keep process pool big enough.. There are some other tricks, but you could saturate 100Mbit network with p3/500 and Apache as well.
I seriously doubt it, not in real world conditions. When you include things like mod_php and mod_perl, those Apache processes get big. Our hosting servers (running Zeus) get 15-20 thousand hits a minute. That's ~333 hits per second. Say each client is downloading 50k images at 2k per second. That means you have 300+ new connections opening per second, that stay open for 25 seconds. So you need to be handling 7500+ concurrent connections.
Keep alives and such will help with this, but a high traffic HTTP server needs to handle at least 1000-2000 connections concurrently. Show me a p3/500 that is running 2000 Apache processes, and processing scripts, etc., and isn't dying. It just won't happen. The process switching overhead alone will kill you. Read this page, then tell me that Apache's I/O model doesn't suck.
Ah, thanks for the info. I was thinking there a way besides using the browser cache. Unfortunately, having IE only check sites once per session breaks a lot of sites, and makes it really difficult when doing web development. I have mine set to check every time. It would be nice if the feature was automatic, similar to how IE will scroll the page to close to where you were before when refreshing (works great on Slashdot discussions).
There's a setting in most browsers to overcome this dissapearing form text. I was forced to learn this from eBay, every time I clicked back to change something I had to compose a whole new auction, really annoying.
Use a lot of test cases. In fact, try everything. Start with a message length one, and send all possible messages. Then try similar, with a length of two. You won't need to try literally every combination, but assuming it's not super complicated, you ought to be able to get it from this.
Slashdot Mirror
I beleive it is intelligent enough to do it on a realtime basis, so you just get several setuid()/setgid() calls.
Umm, no. Think about it for a minute. If a process can change it's euid/egid to anything, then that means uid/gid is root, meaning the process is effectively root. Doing this would mean you give every CGI root access.
This is what makes this type of feature so difficult: there is no way for a master process to change the uid/gid of child processes. Once a child (that is root) changes to a uid/gid, it is stuck for life.
I think the main process simply passes the socket descriptor for the new connection to the virtual host process. Passing descriptors isn't terribly efficient, but it only happens on connection, and certainly more efficient than piping data the way you describe. I'm pretty sure the Apache 2.0 design is efficient and scalable.
Apache 1.3 doesn't pass descriptors between processes. The main process runs as root, binds to the appropriate addresses and listens for connections, then forks off child processes, which all listen or accept on those descriptors (possibly using a mutex to avoid the thundering herd problem).
There isn't any real efficiency problem with passing descriptors (unless some OS's do things weirdly). The issue is that there isn't a portable way to do it.
If you're running cgi instead of some kind of persistent process, who cares about security -- your site runs like molasses anyway...
Yep, absolutely. But what do you do in a shared hosting environment?
> Which means that php would have to be running as a external executable, which means performance drops.
"Drops" doesn't matter, the important question is, "drops by how much?" For sufficiently small values of 'drop', the security increase would be well worth the tradeoff.
Drops like a rock. While I can't give exact numbers, I can say it is quite noticable.
We use Zeus for our hosting servers (Apache won't cut it for high traffic) and have it run all CGI scripts (PHP, Perl, etc.) as CGI's that run as the uid/gid of the customer. On dual CPU 1ghz+ machines with 1gb+ RAM, there is a noticable difference when running a lot of scripts. The same small number of scripts (with 500+ requests/sec most are static) cause the same load under Apache.
While it would be great to be able to run PHP under FastCGI, as the performance increase would be great (even better than mod_php4 under Apache), we have to keep it secure for our customers.
Anyone want to modify FastCGI PHP to have process pools for different users? It wouldn't be fun at all.
That's great it displays text backwards and all, but mirrors don't reverse the order text. Make yourself a nice big "R" and hold it in front of a mirror. See the difference?
If you use a mirror to read this google mirror you are going to see the letters in the right order, but they are all going to be backwards!
It is possible (and easy) to reverse the entire page with IE: http://x42.com/test/flip.html
No, you shouldn't. Maildir solves a problem that doesn't need solving, and it is much, much slower than just about any other mailbox format.
Really? How do you safely modify or delete a message from an mbox file? You make a new file and copy the existing one while changing the data that you need changed and then atomically replace the original file. This means you use double the space of the mbox file and take the time to rewrite the entire file. Or, you modify the original mbox file and hope the system doesn't crash while doing so or you risk corrupting the entire thing. And you have to deal with locking in both cases. How is this better than Maildir?
As for being slow, there are benchmarks to prove you wrong (on courier-mta.org).
Check out MenuetOS, "a fully 32 bit assembly written, graphical OS for asm programming, distributed under General Public License". My friend joked that it ran faster under VMware than Windows does natively.
Actually, remapping the keys for use in the normal calculator modes is not a very simple thing to do on the TI calcs. You'd have to register an interrupt handler, and I think the only free memory the calc won't shuffle around is the memory used for the graphics screen. So, while you had the buttons remapped, you couldn't graph.
:)
Right, the 82 and 85 did not have assembly support built in, so interrupt handlers are more trouble. Though quite possible. One of the shells with interrupt support comes with a demo that leaves a grayscale background while in the TI-OS.
However, I was talking about the TI-86, which does have assembly support and has a lot of built in hooks (such as the [sqrt] programs). I did a lot of programming in assembly for that calculator and if you look on ticalc.org, you will find a lot of demos that show you how to do things like that in the TI-OS. A good one to look at is Kirk Meyer's April Fools program. It completely rearranges the keyboard. A good joke to play on someone
The hooks for the 86 let you do a lot of stuff. You can remap the keyboard, modify system menus, modify the parser, change output, hook into the grapher, run programs at startup, etc. Pretty much anything you want to do is possible if you're willing to do some digging in the ROM. The hardest part is keeping the TI-OS from crashing when you modify things that you shouldn't.
If you're interested, take a look at this set of hook demos by Clem Vasseur. It's a good example of what can be done and if you actually want to write a hook, then most of the hard work is done for you:
http://david.acz.org/hooks.zip
The TI-83 line has built in assembly support, but it is not as good as the 86's, and those calculators suck anyway, so do not consider buying them. The 86 is the best calc overall, especially if you want to have fun programming. The 89 and 92 are ok, have more RAM and a faster CPU (68k instead of z80), but aren't as "clean". The 86 lets you do cool grayscale and has a lot of free RAM to play with. The 83 line can't really do grayscale, don't have much RAM and the screen is smaller (96x64 vs 128x64). The 86 is a fun device to progam.
While TI graphing calculators don't have the hex buttons where you want them, they are very programmable. The TI-86 is reasonably priced and very programmable. You could write yourself a simple conversion app with remapped buttons in TI-BASIC, or go all out and integrate it into the TI-OS using an assembly language program. There are many sites with resources to help you and assembly language mailing lists to get help on. You can do so many cool things with these calculators. Remapping the keys and writing a simple conversion app would be simple.
Damn all you insensitive people with window offices. I work in the basement. I have noticed that the flat pannel monitor I use does a good job of cutting down on the glare from the florecent bulbs. Which brings me to my point. Roomer has it(according to the best buy salesman) that a flat screen TV cuts glare by 60-80%. I would imagine the same would hold true to a flatscreen monitor or flat pannel monitor.
I too have to work in a basement with only a sliver of a window to provide natural light. The only light I use in the room is an Eclipse Light. These things absolutely rock. They eliminate glare completely and light up the work area perfectly. And they look cool too (although the older ones were cool looking IMO).
Qmail is licensed in such a way as to rule out forking.
Wrong. qmail is not licensed at all (it is "no license" software). Thus you only have the right to use it, not distribute it. The right to use it inherently includes the right to create and distribute patches: http://cr.yp.to/softwarelaw.html
Maybe this is why MySQL isn't as popular for database(for things other then a website)?
If you are a real DBA, then having to use a SQL console or command line tools to administrate a database shouldn't be a problem. If you need to point and click to make a backup or create tables because SQL is too hard, then there is no way you can be a DBA. Besides, there is a good web based GUI, phpMyAdmin, that lets you do most things without knowing everything about SQL. There are also GUI interfaces to MySQL.
Also, PHP more popular then ASP? Possibly. But name anyone who makes money running a huge website (Slashdot excluded, they don't make money) with MySQL. There may be some, but anyone who is doing serious business isn't going to be using MySQL.
That's complete FUD. Say, do you work for Microsoft or Oracle? I can say first hand that directNIC.com uses MySQL for everything. They are a very popular domain registrar (sold over half a million domains) and are certainly making money. Many other companies use MySQL and not just for running websites. You should rethink your myths.
Fantastic is such a subjective word. Let's just say they are good.
Apache is obviously not fantastic (see my previous posts for why I think that), but it works well for many people. PHP is a good and I personally really enjoy using it, but I certainly wouldn't call it fantastic, mainly due to its quirks and because the developers refuse to fix certain bugs. MySQL is fantastic. It is easy to use and does what it is designed to do very well.This is better. This type of thing was known to crash Windows 95/98 machines.
OK, I'm not a Linux man: but I didn't think Linux actually supported proper asynchronous I/O. And the acryonym, for better or for worse, is still LAMP and not FAMP or SAMP (or even SAOP). (WISA, anyone? :-) ) Sure, you can pass a shed-load of sockets into a select() call but I can't see select()'s efficiency being even close to linear in set size.
Linux does not support the POSIX AIO interface with a standard kernel (SGI has an implementation available). The supported Linux method is realtime signals. While there is probably a good reason that they chose this non standard, Linux specific method (besides the "because we can"), I haven't seen anything documenting the reasoning.
Another method, /dev/epoll, is somewhat similar to Solaris' /dev/poll. It is more efficient and has (IMHO) a cleaner interface than the realtime signals. Hopefully this patch will make it into the mainstream kernel.
The following page is an excellent reference on I/O models: http://www.kegel.com/c10k.html
And, yes, both select() and poll() both have scalability limits somewhere after a few thousand descriptors. However, a non blocking server using these will still be much more scalable than a multiprocess blocking server such as Apache. The overhead of that many processes will kill you.Do they use non blocking I/O to serve static content? Even when serving dynamic content, the majority of the requests will be for static content. Therefore, to get the best performance, non blocking I/O must be used. Multithreaded servers have an inherent performance limit. On many UNIX systems, threads are as heavyweight as processes.
When will you stop bitching and join the Apache devel team to help make it secure? When will you submit a non-blocking I/O patch to the Apache codebase?
Apache can't be made secure for the same reasons that BIND and Sendmail can't be made secure. It needs to be completely rewritten using secure coding practices. You can't just keep fixing security bugs and hope you found them all.
If you knew anything about Apache's design, then you would know that it's impossible to just add non blocking I/O. The entire server would have to be redesigned. If you read the Apache development list, then you will see that this is never going to happen. The developers don't care. They seem convinced that it is too much work and get upset when anyone mentions the idea of non blocking I/O. There are more than technical issues that need to be solved before Apache can become a better server.
If you don't like the direction they are going, either don't use it or join the devel team. There's no need to bitch and moan about it like it intimately affects your life.
So I'm no longer allowed to give my opinion? I thought that was the purpose of this comment forum.
Apache is NOT the fastest out there...but it is the most configurable (PHP, Perl, etc) and the best all-around webserver there is. Many of us think that the Apache team has done great work and we apprieciate every minute of it.
Yes, that's exactly my point. It's the best we have and no one seems to care that it could be ten times better. And no, it's not just a matter of a few patches. Apache's design is fundamentally flawed.Great. So the Apache group has once again proven that they can deliver both a slow and insecure web server. How many more security holes will Apache have before it is "secure"? And when will Apache deliver truly high performance by having a non blocking I/O model?
What are our choices for web servers on UNIX platforms? Unfortunately, not many good ones. It looks like if you want speed, fast dynamic content and lots of configurability then Zeus Web Server is the only real option. The downside is that it's not open source and has a hefty price tag (although it is well worth it).
Boa is a nice, simple, fast web server that supports dynamic content through CGI's (so not much performance). publicfile's httpd is about the ultimate small, simple, fast and secure web server that supports only static content. If you must have a secure web server, this it (for example, defcon.org uses it). While it is a blocking server, it's small size (two data pages) should lead to performance comparable to that of larger, non blocking servers.
Why isn't there a fast (non blocking) web server that supports fast dynamic content such as PHP, either built in (yuck) or through an API like FastCGI, available for UNIX platforms?It works just fine when compiled against Cygwin.
If you like WordStar and QEdit editors, then you'll probably love JOE.
Have you tried Quanta? It rocks. On topic, I also use and endorse HomeSite for Win32, it's pretty slick.
I tried Quanta about nine months ago, but the fonts sucked and made it unusable. I set the colors exactly the same as on Windows, and used the same TTF fonts from Windows (which for Courier New, is free from Microsoft). In KDE, there is way too much spacing between lines, and you can't make the fonts bold in the color coding settings like you can in HomeSite (at least, it doesn't work). Also, the editor is missing a lot of important features that HomeSite includes, like the visible margin and gutter with line numbers.
Unfortunately, it's just not a replacement for HomeSite yet. I took screenshots of the editors in Windows and KDE to illustrate the difference. If anyone can explain how to make the fonts look exactly the same in KDE, then I might try KDE again. For me, this a huge usability problem that keeps me in Windows for my workstation desktop.For anything web related (HTML, CSS, PHP) I use HomeSite. It works. Great editor, nice syntax highlighting, lots of nice features. I haven't found anything even remotely comparable for Linux, unfortunately. For C/C++, C++Builder is excellent. The syntax highlighting works well and the editor is amazingly fast. Works on files of literally any size with no slowdowns.
Common, have you tried to tune Apache? Process-per-connection not a problem - you just have to keep process pool big enough.. There are some other tricks, but you could saturate 100Mbit network with p3/500 and Apache as well.
I seriously doubt it, not in real world conditions. When you include things like mod_php and mod_perl, those Apache processes get big. Our hosting servers (running Zeus) get 15-20 thousand hits a minute. That's ~333 hits per second. Say each client is downloading 50k images at 2k per second. That means you have 300+ new connections opening per second, that stay open for 25 seconds. So you need to be handling 7500+ concurrent connections.
Keep alives and such will help with this, but a high traffic HTTP server needs to handle at least 1000-2000 connections concurrently. Show me a p3/500 that is running 2000 Apache processes, and processing scripts, etc., and isn't dying. It just won't happen. The process switching overhead alone will kill you. Read this page, then tell me that Apache's I/O model doesn't suck.Ah, thanks for the info. I was thinking there a way besides using the browser cache. Unfortunately, having IE only check sites once per session breaks a lot of sites, and makes it really difficult when doing web development. I have mine set to check every time. It would be nice if the feature was automatic, similar to how IE will scroll the page to close to where you were before when refreshing (works great on Slashdot discussions).
There's a setting in most browsers to overcome this dissapearing form text. I was forced to learn this from eBay, every time I clicked back to change something I had to compose a whole new auction, really annoying.
How do you do that in IE and Mozilla?Use a lot of test cases. In fact, try everything. Start with a message length one, and send all possible messages. Then try similar, with a length of two. You won't need to try literally every combination, but assuming it's not super complicated, you ought to be able to get it from this.