And probably, reluctantly even after years of *nix use, for case insensitivity.
As Donald Norman has commented, if lots of people use something incorrectly there is probably a problem with the design, not the people. I will admit to having on more than one occassion typed "less readme" instead of "less README" or scrolled through a file listing and overlooked a file that was sorted elsewhere due to capitalization.
Even worse is the fact that subparts of an item follow different rules. For example:
http://slashdot.org/index.html == http://SlashDot.ORG/index.html
due to required case-insensitivity of domains,
http://slashdot.org/index.html != http://slashdot.org/Index.html
unless the underlying OS/web/app-server chooses to interpret them as equivalent.
As some have commented, everyone sees a difference between joe doe, Joe Doe, JOE DOE and jOe doE but they all know that in every case we are referring to the same person. In fact many places standardize on all-caps for the family name in forms and documents to reduce errors.
To those who say that the problem should be solved on the application level: consistency is good - a user should not have to remember the quirks of each application. Even if one is a slave to point-and-click GUIs there are problems created by sorting and the possibility of multiple files with the "same" name.
Windoze is also brain dead. Although it is case insensitive, it also changes the case of file names in one of its many misguided attempts to "help" the user.
My preference would be to have the OS keep the filename in whatever form of caps/lowercase that I choose but to treat files in a case-insensitive manner.
In fact, I think that given the traffic commission's mandate to reduce congestion, their best response would not be "here's your ticket" but rather "How'd you do that?!?":)
Big Black Ships? mysterious humming drive systems?
How did this get by the/. editors.
I know it is an "argumentum ad hominem" but just do an AltaVista search and see all the people who link to the "National Institute of Discovery Science" and you will not find a bunch of references in serious scientific journals.
You will, however, get a reasonably comprehensive list of UFO whako sites. A small sample:
I just returned from the Pacific Cup race from San Francisco, CA to Kaneohe, HI and was in charge of the computers. We carried two laptops primarily as backup and to use with the Iridium phone but the main computer was a Capuccino
from Think Geek.
We mounted a Tote Vision
monitor on an adjustable arm at the nav station and controlled it with a wireless keyboard and wireless mouse. The Tote also includes a TV receiver so you can eliminate one other piece of equipment.
For our use we needed more serial ports so we got a USB-serial converter box which gave us a total of one on the PC plus 4 external. For the race we collected HF weatherfax using mScan meteo software. The software controlled an ICOM PCR-1000 general coverage receiver via. the serial port and used the internal sound card to receive the weatherfax data.
Another serial port was dedicated to the B&G tactician software to B&G instrument connection.
The next port provided NMEA GPS input to the Nobletec navigation program and another provided general NMEA instrument data to Nobletec (the Nobletec software can display maps as well as a console with wind info, boat speed, heading, water temperature and whatever else your instruments collect).
Finally, another port sent NMEA navigation info back from Nobletec to the onboard instruments for display to the driver (range/bearing to waypoint, cross track error, etc.)
The whole thing worked great (we won our division!).
The advice is somewhat obvious - keep the computer dry. We mounted the PC and Icom behind the breaker panel as electrical areas are generally pretty dry on a boat. The whole thing runs on 12v so we didn't need to run the ship's inverter. (Capuccino uses a 12v-18v adapter, Tote is 12v native. The Canon printer is 13.6v and worked great only when the batteries were fully charged).
Heat build-up is a problem on hot days or in the tropics so we added a fan to pull air through the instrument/electrical compartments. This solved our heat-related crashes.
Access to the computer requred twisting two screw latches so it was pretty easy but not convenient if you need to access the CD a lot. It's likely that you could find a spot near your nav table to mount the mini-PC where you could access the disk easily.
I know many people who live and work on their boats. Most use laptops but one uses regular PCs with a huge LCD monitor. None have really had any trouble but they don't leave the computers where they are exposed to the elements. Usually a boat that is large enough to live on has some dry areas.
As to the other question, you need industrial electronic enclosures. I don't recall which companies make them but my former roommate worked on systems that were used in food packing and they used standard enclosures designed to withstand the 180 degree 1000psi pressure wash that they used to clean the processing equipment. Google??
The time of day (week/month) a system is down is as important as how much of the time.
Our hosting company blew out a (supposedly) fully redundant Cisco and took us down for 1.5 hours in the middle of what was at the time our peak day in history. This impacted hundreds of thousands of visitors.
The same downtime at 1:00 am would have had about 1% of the impact on users even though the availability statistics would show both to be identical.
Naturally systems tend to fail more often under high load when the impact on your user base will be the greatest.
Impact on your user base is a better measure of the impact of downtime.
Ferrets love to crawl through small places (see previous comments on escape problems) so they were used in WWII to pull leader-lines through the wiring conduits in aircraft. Imagine showing up to help pull network cable and pulling a ferret out of your toolbox:).
Seriously, a former girlfriend of mine did have a pet ferret and it was fun but somewhat high maintenance. They do smell but most people have the scent glands removed which pretty-much deals with the problem. We never had a real problem with smell after the operation.
Like dogs, they love to grab onto things with their teeth which are sharp and they will sometimes draw blood. We never had it try to hurt someone, though. If you jumped, it would stop playing almost as if it was sorry it hurt you.
Read on..."Stuff that matters". So it's not earthshaking on a war/pestilence/famine scale but for many of us this is a truly sad day.
The Who is really the *only* band whos concerts I would seek out. I was trying to figure out how to rearrange my schedule and see them when they visited the bay area next month.
There really was nothing like seeing this statue on the side of the stage and then having one of the big monitors zoom in on his fingers and only see a blur.
Seriously, four points need to be made to management.
One. Relying on a single vendor is every bit as dangerous as building a stock "portfolio" with just one stock. Diversity is good.
Two. Support exists - you might try compiling a list of support options. Include both the free (newsgroups, web sites, etc.) and the not free (list the consulting companies that specialize in the software you use).
Three. Big vendor and single vendor are not the same as good support. One need merely read the Gripe Line column in InfoWorld to see how shabby the (often very expensive) "support" is from many large and supposedly solid and reputable companies.
Four. The right to use the code indefinitely prevents abuse by vendors. It is no fun investing lots of effort building systems (code you develop and own) only to have a vendor pull the rug out from under you when they cease supporting or selling a product or when they switch licensing schemes to make continued use unaffordable.
You need to outline the various risks and have the administration determine a policy. That both gives you a basis for your technological decisions and it covers your a**. Start by determining the purpose of allowing access - is it just for web research or do you want to provide other access as well?
Some potential problems:
Unlimited and unlogged access?? What a great place for spammers, crackers and such to get net access.
Everyone on the same subnet (w/o router restrictions)?? Everyone with open Windoze shares will be vulnerable while logged in.
Log all access?? You may run afoul of privacy concerns and laws.
If you only intend to provide http(s) and ftp you might consider putting users behing a Squid proxy to improve speed and help limit access (not a substitute for firewalling, though).
I would in any case make sure that the IP (or even entire connection) you use is separate from your administrative connection so if something bad happens (you provided full access and got blacklisted for spam for instance), your administrative functions will not be impaired.
You have provided way too little info. First, do you really mean scalable or do you mean high-traffic. They are not the same thing. You can build a high-traffic site using technology that won't cluster/expand well and be screwed when you need a higher-traffic site. Converesly you can build a very low-traffic site that will scale quite well (a technology that allows you to easily add hardware as your traffic dictates for example).
It would be helpful to know, for example, what portion of the traffic (both # of requests and bytes) is static and what is dynamic (include images)? What is the peak (say 98th percentile) expected traffic? What are typical page sizes and how much are they compressible with gzip? etc.
Apache itself doesn't really handle dynamic content - its modules or an underlying app server do that. That is probably where you will have to do the most work.
As another poster mentioned, persistent database connections are essential. You may want to look into a "real" app server. JBoss is open source and just won some awards at Java One. If that is too much complexity at least be sure to use persistent connections in whatever other technology you select.
Persistent connections have a down side. Don't forget that your underlying database must be able to handle both your number of requests and your number of connections. If you just increase Apache processes you may find that the database is unable to manage that many simultaneous connections efficiently. Opening/closing connections for each request kills you. Maintaining hundreds of open connections kills you. This is one of the real strengths of any technology that can handle connection pooling - you will probably find that you only need a handful of connections to handle lots of front-ends and connection pooling allows you to do it efficiently. It can also help you scale by distributing connections to multiple database servers for you when your needs dictate.
The faster you can dispense with a request the better. This includes not only all your processing time but the transmission time to the client. A process/thread can't move on till the client has the data. Therefore...
Design your pages to give yourself a fighting chance. For example: if you have any static images be sure to set your http headers to prevent browsers from reloading them. Even the request overhead to the server to determine that the cached image is up-to-date is more than the size of the image itself so set a LONG expiration.
Trim unnecessary whitespace, using short names (ie. i/x.png instead of buttonimages/left_page_arrow_top.png) and so on.
If the pages are large enough and the clients slow enough then you may want to use gzip (mod_gzip) to compress the data. It will cost you processing time to compress dynamic content but will save you transmission time. If you pay for bandwidth you can see a 50-80% reduction in your bandwidth usage as well.
Note: if your spec of "non-clustered" and scalable still allows multiple machines and if you do have images or other static content you may want to move that content to a separate machine. The Linux kernel http server screams on static content (of course the static-content load on your server may be so small a percentage that it isn't worth the effort).
Try Apache 2.x first. One problem with 1.x on most (all??) platforms is the "thundering herd" problem. You may try to increase performance by running lots of processes but when a request comes in, all sleeping processes are awoken (the thundering herd) and although only one will end up servicing the request, the effect of waking up huge numbers of sleeping processes can be "bad".
Be sure to test with clients of varying speed. We discovered we could crash a site faster with slow clients than fast. Once while testing a Cold Fusion/IIS site it seemed like we could realy get some screaming throughput when testing on the LAN. Unfortunately when the server had to keep threads/connections alive long enough to service slow clients it wasn't so pretty. When we ran the simulation that way we could crash the server in 2 seconds.
Give me more specifics and I may be able to give better advice.
Still, my most memorable freshman programming assignment (punch cards/line printer/mainframe no less) was to simulate a cocktail party.
The party was a two-dimensional array representing the room. At the edge was a door and in the center was the bar.
You fed the program a list of guests including name, arrival time, planned departure time and how interesting the person is.
Guests arrive and go first to the bar. From there they mingle by trying to move a square at a time if it will make the average "interestingness" of those surrounding that square more interesting that the average surrounding their current square.
If the guest cannot move to a square such that the surrounding guests are, on average, more interesting the guest is then he will go back to the bar.
One last provision...each trip to the bar causes a guest to become one point less interesting but to think he is one point more interesting and each drink also increments the planned departure time by one.
Slashdot Mirror
As Donald Norman has commented, if lots of people use something incorrectly there is probably a problem with the design, not the people. I will admit to having on more than one occassion typed "less readme" instead of "less README" or scrolled through a file listing and overlooked a file that was sorted elsewhere due to capitalization.
Even worse is the fact that subparts of an item follow different rules. For example:
http://slashdot.org/index.html == http://SlashDot.ORG/index.html
due to required case-insensitivity of domains,
http://slashdot.org/index.html != http://slashdot.org/Index.html
unless the underlying OS/web/app-server chooses to interpret them as equivalent.
As some have commented, everyone sees a difference between joe doe, Joe Doe, JOE DOE and jOe doE but they all know that in every case we are referring to the same person. In fact many places standardize on all-caps for the family name in forms and documents to reduce errors.
To those who say that the problem should be solved on the application level: consistency is good - a user should not have to remember the quirks of each application. Even if one is a slave to point-and-click GUIs there are problems created by sorting and the possibility of multiple files with the "same" name.
Windoze is also brain dead. Although it is case insensitive, it also changes the case of file names in one of its many misguided attempts to "help" the user.
My preference would be to have the OS keep the filename in whatever form of caps/lowercase that I choose but to treat files in a case-insensitive manner.
Good point.
:)
In fact, I think that given the traffic commission's mandate to reduce congestion, their best response would not be "here's your ticket" but rather "How'd you do that?!?"
Big Black Ships? mysterious humming drive systems?
/. editors.
n ge.net
www.ufodisclosure.comg onuforeview.comd og.comv e.orgo m
How did this get by the
I know it is an "argumentum ad hominem" but just do an AltaVista search and see all the people who link to the "National Institute of Discovery Science" and you will not find a bunch of references in serious scientific journals.
You will, however, get a reasonably comprehensive list of UFO whako sites. A small sample:
www.area51researchcenter.com
www.virtuallystra
www.ufofinland.net
www.ufowisconsin.com
www.aliendave.com
www.ore
ufounderground.net
www.ufowatch
www.truthseekeratroswell.com
www.stardri
www.intrudersfoundation.org
www.ufoinfo.c
www.ufoconspiracy.com
www.artbell.com
You be the judge
I just returned from the Pacific Cup race from San Francisco, CA to Kaneohe, HI and was in charge of the computers. We carried two laptops primarily as backup and to use with the Iridium phone but the main computer was a Capuccino from Think Geek.
We mounted a Tote Vision monitor on an adjustable arm at the nav station and controlled it with a wireless keyboard and wireless mouse. The Tote also includes a TV receiver so you can eliminate one other piece of equipment.
For our use we needed more serial ports so we got a USB-serial converter box which gave us a total of one on the PC plus 4 external. For the race we collected HF weatherfax using mScan meteo software. The software controlled an ICOM PCR-1000 general coverage receiver via. the serial port and used the internal sound card to receive the weatherfax data.
Another serial port was dedicated to the B&G tactician software to B&G instrument connection.
The next port provided NMEA GPS input to the Nobletec navigation program and another provided general NMEA instrument data to Nobletec (the Nobletec software can display maps as well as a console with wind info, boat speed, heading, water temperature and whatever else your instruments collect).
Finally, another port sent NMEA navigation info back from Nobletec to the onboard instruments for display to the driver (range/bearing to waypoint, cross track error, etc.)
The whole thing worked great (we won our division!).
The advice is somewhat obvious - keep the computer dry. We mounted the PC and Icom behind the breaker panel as electrical areas are generally pretty dry on a boat. The whole thing runs on 12v so we didn't need to run the ship's inverter. (Capuccino uses a 12v-18v adapter, Tote is 12v native. The Canon printer is 13.6v and worked great only when the batteries were fully charged).
Heat build-up is a problem on hot days or in the tropics so we added a fan to pull air through the instrument/electrical compartments. This solved our heat-related crashes.
Access to the computer requred twisting two screw latches so it was pretty easy but not convenient if you need to access the CD a lot. It's likely that you could find a spot near your nav table to mount the mini-PC where you could access the disk easily.
I know many people who live and work on their boats. Most use laptops but one uses regular PCs with a huge LCD monitor. None have really had any trouble but they don't leave the computers where they are exposed to the elements. Usually a boat that is large enough to live on has some dry areas.
As to the other question, you need industrial electronic enclosures. I don't recall which companies make them but my former roommate worked on systems that were used in food packing and they used standard enclosures designed to withstand the 180 degree 1000psi pressure wash that they used to clean the processing equipment. Google??
The time of day (week/month) a system is down is as important as how much of the time.
Our hosting company blew out a (supposedly) fully redundant Cisco and took us down for 1.5 hours in the middle of what was at the time our peak day in history. This impacted hundreds of thousands of visitors.
The same downtime at 1:00 am would have had about 1% of the impact on users even though the availability statistics would show both to be identical.
Naturally systems tend to fail more often under high load when the impact on your user base will be the greatest.
Impact on your user base is a better measure of the impact of downtime.
Seriously, a former girlfriend of mine did have a pet ferret and it was fun but somewhat high maintenance. They do smell but most people have the scent glands removed which pretty-much deals with the problem. We never had a real problem with smell after the operation.
Like dogs, they love to grab onto things with their teeth which are sharp and they will sometimes draw blood. We never had it try to hurt someone, though. If you jumped, it would stop playing almost as if it was sorry it hurt you.
Read on..."Stuff that matters". So it's not earthshaking on a war/pestilence/famine scale but for many of us this is a truly sad day.
The Who is really the *only* band whos concerts I would seek out. I was trying to figure out how to rearrange my schedule and see them when they visited the bay area next month.
There really was nothing like seeing this statue on the side of the stage and then having one of the big monitors zoom in on his fingers and only see a blur.
He will be missed.
Pay someone...
Seriously, four points need to be made to management.
One. Relying on a single vendor is every bit as dangerous as building a stock "portfolio" with just one stock. Diversity is good.
Two. Support exists - you might try compiling a list of support options. Include both the free (newsgroups, web sites, etc.) and the not free (list the consulting companies that specialize in the software you use).
Three. Big vendor and single vendor are not the same as good support. One need merely read the Gripe Line column in InfoWorld to see how shabby the (often very expensive) "support" is from many large and supposedly solid and reputable companies.
Four. The right to use the code indefinitely prevents abuse by vendors. It is no fun investing lots of effort building systems (code you develop and own) only to have a vendor pull the rug out from under you when they cease supporting or selling a product or when they switch licensing schemes to make continued use unaffordable.
You need to outline the various risks and have the administration determine a policy. That both gives you a basis for your technological decisions and it covers your a**. Start by determining the purpose of allowing access - is it just for web research or do you want to provide other access as well?
Some potential problems:
Unlimited and unlogged access?? What a great place for spammers, crackers and such to get net access.
Everyone on the same subnet (w/o router restrictions)?? Everyone with open Windoze shares will be vulnerable while logged in.
Log all access?? You may run afoul of privacy concerns and laws.
If you only intend to provide http(s) and ftp you might consider putting users behing a Squid proxy to improve speed and help limit access (not a substitute for firewalling, though).
I would in any case make sure that the IP (or even entire connection) you use is separate from your administrative connection so if something bad happens (you provided full access and got blacklisted for spam for instance), your administrative functions will not be impaired.
You have provided way too little info. First, do you really mean scalable or do you mean high-traffic. They are not the same thing. You can build a high-traffic site using technology that won't cluster/expand well and be screwed when you need a higher-traffic site. Converesly you can build a very low-traffic site that will scale quite well (a technology that allows you to easily add hardware as your traffic dictates for example).
It would be helpful to know, for example, what portion of the traffic (both # of requests and bytes) is static and what is dynamic (include images)? What is the peak (say 98th percentile) expected traffic? What are typical page sizes and how much are they compressible with gzip? etc.
Apache itself doesn't really handle dynamic content - its modules or an underlying app server do that. That is probably where you will have to do the most work.
As another poster mentioned, persistent database connections are essential. You may want to look into a "real" app server. JBoss is open source and just won some awards at Java One. If that is too much complexity at least be sure to use persistent connections in whatever other technology you select.
Persistent connections have a down side. Don't forget that your underlying database must be able to handle both your number of requests and your number of connections. If you just increase Apache processes you may find that the database is unable to manage that many simultaneous connections efficiently. Opening/closing connections for each request kills you. Maintaining hundreds of open connections kills you. This is one of the real strengths of any technology that can handle connection pooling - you will probably find that you only need a handful of connections to handle lots of front-ends and connection pooling allows you to do it efficiently. It can also help you scale by distributing connections to multiple database servers for you when your needs dictate.
The faster you can dispense with a request the better. This includes not only all your processing time but the transmission time to the client. A process/thread can't move on till the client has the data. Therefore...
Design your pages to give yourself a fighting chance. For example: if you have any static images be sure to set your http headers to prevent browsers from reloading them. Even the request overhead to the server to determine that the cached image is up-to-date is more than the size of the image itself so set a LONG expiration.
Trim unnecessary whitespace, using short names (ie. i/x.png instead of buttonimages/left_page_arrow_top.png) and so on.
If the pages are large enough and the clients slow enough then you may want to use gzip (mod_gzip) to compress the data. It will cost you processing time to compress dynamic content but will save you transmission time. If you pay for bandwidth you can see a 50-80% reduction in your bandwidth usage as well.
Note: if your spec of "non-clustered" and scalable still allows multiple machines and if you do have images or other static content you may want to move that content to a separate machine. The Linux kernel http server screams on static content (of course the static-content load on your server may be so small a percentage that it isn't worth the effort).
Try Apache 2.x first. One problem with 1.x on most (all??) platforms is the "thundering herd" problem. You may try to increase performance by running lots of processes but when a request comes in, all sleeping processes are awoken (the thundering herd) and although only one will end up servicing the request, the effect of waking up huge numbers of sleeping processes can be "bad".
Be sure to test with clients of varying speed. We discovered we could crash a site faster with slow clients than fast. Once while testing a Cold Fusion/IIS site it seemed like we could realy get some screaming throughput when testing on the LAN. Unfortunately when the server had to keep threads/connections alive long enough to service slow clients it wasn't so pretty. When we ran the simulation that way we could crash the server in 2 seconds.
Give me more specifics and I may be able to give better advice.
Still, my most memorable freshman programming assignment (punch cards/line printer/mainframe no less) was to simulate a cocktail party.
The party was a two-dimensional array representing the room. At the edge was a door and in the center was the bar.
You fed the program a list of guests including name, arrival time, planned departure time and how interesting the person is.
Guests arrive and go first to the bar. From there they mingle by trying to move a square at a time if it will make the average "interestingness" of those surrounding that square more interesting that the average surrounding their current square.
If the guest cannot move to a square such that the surrounding guests are, on average, more interesting the guest is then he will go back to the bar.
One last provision...each trip to the bar causes a guest to become one point less interesting but to think he is one point more interesting and each drink also increments the planned departure time by one.