ABS does shorten stopping distances on wet or snow covered roads, but if the road is dry, the stop time will be much shorter if the wheels lock and you skid.
What erlander forgot to mention is the simple theory of static versus dynamic friction. The static coefficient of friction (not skidding) is higher than the dynamic coefficient of friction (skidding). If you keep the tires on the top end of static friction, you stop fastest *AND* achieve the end goal of maintaining control.
This is also related to why originally ABS was only on the back tires. Like a motorcycle, the majority of the stopping power is in the front wheels. You keep the back tires from locking up, and the vehicle naturally slides straight (because there's more friction in the back non-skidding tires than the front skidding tires). Nowadays ABS is on all 4 which now allows you to steer around things in front of you.
How about traffic lights transmitting their light cycle and current condition to all close automobiles so that they can adjust their speed to always hit the green light.
What if you're five cars behind the lead car that's slowing down so that it hits the intersection right as it turns green? Do you get warnings saying that your speed is suboptimal? Or does your system accept the consequences of being sixth in line and just relegates itself to the fact that it will have to make it through the intersection long after it has turned green or that it won't make the next green cycle (those few damn fast green lights)? What if the lead car is malfunctioning and going too slow, does your car start honking the horn and flashing a big middle finger laser image in front of the lead car?
Call me a pessimist, but I don't expect any system that takes control away from (if it cannot be presented as "giving power to") the driver will be accepted by the public unless there is a seperate set of lanes that those vehicles will drive on.
We have found that the rpms that are built by the MySQL group work best compared to vendor supplied rpms. We get the version that is built to match the glibc version and walk away. These admins seem to have wanted to use a built by Suse only version and didn't trust anything else. It's their choice I guess.
Like it or not the GPL requires that if a company uses and adds to Linux they have to give back.
No! It says that if you use GPL'd software and add to it AND distribute it, then you have to provide the source to the recipients of your modified products. If you use GPL'd software and add to it and use it internally within your company, you are not required to give back ANYTHING. A good netizen would, but not everybody is one...
It's called wlc (weighted least connection) algorithm. It does what you want because you can infer the loading of the server by how long it takes to close the connection. Also similar to this is the sed (shortest expected delay) algorithm and the nq (never queue) algorithm.
The wlc algorithm does have a small drawback though. When a new server is brought into the cluster, the wlc algorithm hammers the new server since it is starting out with zero connections compared to the active servers. The sed overall seems to be one of the best solutions since it theoretically yields a consistent, nearly average response time for all inbound connections (tries to keep connection response times near the center of the bell curve). The nq algorthm just says to always assign a job to an idle server instead of waiting for a fast one.
Personally we just use wrr (weighted round robin) on a dual LVS system with failover. We haven't had the opportunity to test sed yet, but it looks applicable to our needs. The wrr algorithm Works for our 50-something load balanced hosts handling about 120 million packets per day (mostly http and https, but also ldap internally), so we don't "fix it". We don't use shared disks, so we avoid a lot of the complexities inherent with those types of systems.
About half the students said the government can restrict any indecent material on the Internet. It can't.
Well, unfortunately it HAS been restricting indecent material. Forcing various institutions to enable filters on content.
Many will say that the government cannot restrict indecent material and for us that's correct. However, don't forget the limited view these kids have of the Internet (yes, Gore's internet). They're in a school connected to an internet that is HIGHLY filtered and restricted by their school district. Federal Law requires it. It's no wonder they think the government can and is doing that for everybody. They don't have enough real world experience yet to know any better (with a few exceptions as always).
Everybody is missing the (lack of) importance here. Read the description of the rating:
...a level of protection which is appropriate for an assumed non-hostile and well-managed user community requiring protection against threats of inadvertent or casual attempts to breach the system security.
This specifically precludes internet usage (unless you consider connecting to the internet to be non-hostile, in which case your paranoia badge is revoked).
It DOES however open a door to let competitors into a controlled market and it does provide a measuring stick, although the things it measures aren't relevant. It's like recording a live rock show by putting mikes on the roadies instead of the band.
Johnny Cash once told me that Jesus wrote a song and it was called "Why Me Kris." -- Kris Kristofferson
Even better is that it details a superior system (albeit pricey per node). It's based on military technology and military technology is light years ahead of what most of us are using on a daily basis.
It needs to be done at the ISP level. Those at the core can't really do it because of the CPU horsepower it would require. Adding just a couple of ACLs reduces the throughput from maximum. Google for NANOG and search their archives (third link).
Of late, more and more DDOS are not using spoofed IP's (thought egress filtering would certainly help).
Do they keep dependencies at a minimum?
The answer is you set dependencies to what the package requires. It's not a "Mandrake hates you so they require 800 packages for php to work" type thing. One guy has even done HUGE research and experimentation to convert apache/php/ldap/imap to a completely modular setup. If you have ever compiled php into apache using source, you know that in order to upgrade one, you must upgrade BOTH (and it's worse if you have imap and ldap in the picture). Mandrake provides mod_* rpms so that these extra functions are completely modular and can be added/removed/upgraded at will. I am unaware if RH offers these same packages. All they have to do is use the spec files from the src rpms.
Do they keep library versions well syncronized with available apps?
If you're mixing and matching packages from older distros or other distros, then you will have problems. If it absolutely refuses to install the rpm, grab the.src.rpm and recompile that. There's a great article by the Mandrake gurus on how to make rpm packages. You might have to make some minor tweaks to the spec file and/or recreate the patches, but it's definitely easier than building everything from source with all the correct features enabled, and all the ones that cause problems disabled, etc...
Is the auto update tool easy to use? That is, does it present dependencies clearly and show you release notes and advisories. I'd like to know *why* Apache has been updated, so I know if it really affects me.
The auto update tool...if you mean something that runs in a cron job like apt-get every night, I think you will be disappointed. But if you mean "select a package from a list of available packages and have it automatically fulfill dependencies either locally or from a defined ftp site", then the answer is yes. As far as *why* apache was updated, I do not think that security issues are normally recorded in the rpm descriptions, but I could be wrong.
Can I depend on the vendor to quickly release security critical updates. If I have to resort to source in an emergency, it defeats the whole point of packaging.
There are guys that monitor security aspects as the primary focus of their job. They verify/classify the security reports on places like BugTraq and then upgrade the packages and release them to the mirrors. But you always have the option that I described above. Grab the source, tweak the.spec file, and make your own rpms. It's not that hard. It IS a learning curve, but once you get past that, you'll be rpm'ing your way to the drugstore for more fix.
Slashdot Mirror
What erlander forgot to mention is the simple theory of static versus dynamic friction. The static coefficient of friction (not skidding) is higher than the dynamic coefficient of friction (skidding). If you keep the tires on the top end of static friction, you stop fastest *AND* achieve the end goal of maintaining control.
This is also related to why originally ABS was only on the back tires. Like a motorcycle, the majority of the stopping power is in the front wheels. You keep the back tires from locking up, and the vehicle naturally slides straight (because there's more friction in the back non-skidding tires than the front skidding tires). Nowadays ABS is on all 4 which now allows you to steer around things in front of you.
What if you're five cars behind the lead car that's slowing down so that it hits the intersection right as it turns green? Do you get warnings saying that your speed is suboptimal? Or does your system accept the consequences of being sixth in line and just relegates itself to the fact that it will have to make it through the intersection long after it has turned green or that it won't make the next green cycle (those few damn fast green lights)? What if the lead car is malfunctioning and going too slow, does your car start honking the horn and flashing a big middle finger laser image in front of the lead car?
Call me a pessimist, but I don't expect any system that takes control away from (if it cannot be presented as "giving power to") the driver will be accepted by the public unless there is a seperate set of lanes that those vehicles will drive on.
That part of a motor is a little too phallic IMHO to drive performance.
We have found that the rpms that are built by the MySQL group work best compared to vendor supplied rpms. We get the version that is built to match the glibc version and walk away. These admins seem to have wanted to use a built by Suse only version and didn't trust anything else. It's their choice I guess.
You misspelled "Texas".
It's called wlc (weighted least connection) algorithm. It does what you want because you can infer the loading of the server by how long it takes to close the connection. Also similar to this is the sed (shortest expected delay) algorithm and the nq (never queue) algorithm.
The wlc algorithm does have a small drawback though. When a new server is brought into the cluster, the wlc algorithm hammers the new server since it is starting out with zero connections compared to the active servers. The sed overall seems to be one of the best solutions since it theoretically yields a consistent, nearly average response time for all inbound connections (tries to keep connection response times near the center of the bell curve). The nq algorthm just says to always assign a job to an idle server instead of waiting for a fast one.
Personally we just use wrr (weighted round robin) on a dual LVS system with failover. We haven't had the opportunity to test sed yet, but it looks applicable to our needs. The wrr algorithm Works for our 50-something load balanced hosts handling about 120 million packets per day (mostly http and https, but also ldap internally), so we don't "fix it". We don't use shared disks, so we avoid a lot of the complexities inherent with those types of systems.
Many will say that the government cannot restrict indecent material and for us that's correct. However, don't forget the limited view these kids have of the Internet (yes, Gore's internet). They're in a school connected to an internet that is HIGHLY filtered and restricted by their school district. Federal Law requires it. It's no wonder they think the government can and is doing that for everybody. They don't have enough real world experience yet to know any better (with a few exceptions as always).
Blue skies...
For what? The Chewbacca defense? Doubtful he'll work pro-bono.
This specifically precludes internet usage (unless you consider connecting to the internet to be non-hostile, in which case your paranoia badge is revoked).
It DOES however open a door to let competitors into a controlled market and it does provide a measuring stick, although the things it measures aren't relevant. It's like recording a live rock show by putting mikes on the roadies instead of the band.
Johnny Cash once told me that Jesus wrote a song and it was called "Why Me Kris." -- Kris Kristofferson
For an excellent explanation of why this type of thing occurs, check out:
C ellWhitePaper/TurboCell%20White%20Paper.htm
http://www.karlnet.com/Documents/WhitePaper/Turbo
Even better is that it details a superior system (albeit pricey per node). It's based on military technology and military technology is light years ahead of what most of us are using on a daily basis.
Blue skies...
It needs to be done at the ISP level. Those at the core can't really do it because of the CPU horsepower it would require. Adding just a couple of ACLs reduces the throughput from maximum. Google for NANOG and search their archives (third link).
Of late, more and more DDOS are not using spoofed IP's (thought egress filtering would certainly help).
Do they keep dependencies at a minimum?
.src.rpm and recompile that. There's a great article by the Mandrake gurus on how to make rpm packages. You might have to make some minor tweaks to the spec file and/or recreate the patches, but it's definitely easier than building everything from source with all the correct features enabled, and all the ones that cause problems disabled, etc...
.spec file, and make your own rpms. It's not that hard. It IS a learning curve, but once you get past that, you'll be rpm'ing your way to the drugstore for more fix.
The answer is you set dependencies to what the package requires. It's not a "Mandrake hates you so they require 800 packages for php to work" type thing. One guy has even done HUGE research and experimentation to convert apache/php/ldap/imap to a completely modular setup. If you have ever compiled php into apache using source, you know that in order to upgrade one, you must upgrade BOTH (and it's worse if you have imap and ldap in the picture). Mandrake provides mod_* rpms so that these extra functions are completely modular and can be added/removed/upgraded at will. I am unaware if RH offers these same packages. All they have to do is use the spec files from the src rpms.
Do they keep library versions well syncronized with available apps?
If you're mixing and matching packages from older distros or other distros, then you will have problems. If it absolutely refuses to install the rpm, grab the
Is the auto update tool easy to use? That is, does it present dependencies clearly and show you release notes and advisories. I'd like to know *why* Apache has been updated, so I know if it really affects me.
The auto update tool...if you mean something that runs in a cron job like apt-get every night, I think you will be disappointed. But if you mean "select a package from a list of available packages and have it automatically fulfill dependencies either locally or from a defined ftp site", then the answer is yes. As far as *why* apache was updated, I do not think that security issues are normally recorded in the rpm descriptions, but I could be wrong.
Can I depend on the vendor to quickly release security critical updates. If I have to resort to source in an emergency, it defeats the whole point of packaging.
There are guys that monitor security aspects as the primary focus of their job. They verify/classify the security reports on places like BugTraq and then upgrade the packages and release them to the mirrors. But you always have the option that I described above. Grab the source, tweak the
Blue skies... Cannonball