I've witnessed and worked on deployments of sites that bang massive loads, and you know what? If your site is pulling a million hits a day and you're attempting to box that into one server, then you're a complete moron and deserve to suffer those crashes. No OS is going to save you from that.
We must work in different worlds. In the Linux/Apache world I inhabit, serving a million hits a day on a single machine is no big deal. Up until early this year, I had a dual-processor 300MHz Linux box with 256M RAM that served 1.4 million, in addition to doing DNS and mail (over 30,000 messages per day). It's load average started going over 1 during peak time, so I moved it to an 850MHz Athlon.
I've witnessed and worked on deployments of sites that bang massive loads, and you know what? If your site is pulling a million hits a day and you're attempting to box that into one server, then you're a complete moron and deserve to suffer those crashes. No OS is going to save you from that.
We must work in different worlds. In the Linux/Apache world I inhabit, serving a million hits a day on a single machine is no big deal. Up until early this year, I had a dual-processor 300MHz Linux box with 256M RAM that served 1.4 million, in addition to doing DNS and mail (over 30,000 messages per day). It's load average started going over 1 during peak time, so I moved it to an 850MHz Athlon.
The problem here is not so much the database server as the database design.
Any time you can get a credit card number via a normal database query it is a security hole.
I will say it again -- anytime you can query your database and get a credit card number it is a security hole. If you are not saving the information to a non-internet connected system, or encrypting with strong encryption before writing it to disk, you are playing fast and loose with customer information.
The simple rule should be this -- an unencrypted credit card number should never be written to disk, not even for a moment.
I agree. I also accelerated the switchover of my clients because of Verisign's spam.
The following companies also have root-signing certificates in Navigator 4.7:
ABAecom (Am. Bankers Assn) ANX Network AT&T Access America (DST) American Express BBN BelSign Canada Post Corp. DST (provider to quite a few others) E-Certify Entrust (DST) Equifax GTE CyberTrust GlobalSign IBM KEYWITNESS MCI Mall National Retail Federation (DST) Novell (DST) TC TrustCenter UPS United States Postal Service Uptime Group
I roger the choice of Gnome and Enlightenment. I am a keyboarder from way back, and I stuck with FVWM 1.2x for a long time because the hotkey management in other window managers seemed to be very poor. I would probably be a KDE user today but for their fixed ALT-TAB for window alternation in the first versions.
I use ALT-N to change between windows. Enlighenment allows you to change focus only in the current desktop, which is just what I want. I use CTRL- to move between desktops and ALT-P to return to the anchor desktop (those keys are relics of an old DOS window manager called Desqview).
Bottom line is I don't use my mouse except for web browsing; that is partly enabled by my choice of applications (vim, mutt, tin, ncftp, and xterm). I am starting to use StarOffice some (goodbye, Windoze!) and there I have to use the mouse a bit. But even then, once I am in the doc they have some pretty good key shortcuts.
> This little bit of mail ended up being nearly a > megabyte with the attachments converted into base-64. )-:
A megabyte isn't what it used to be. 8-)
> A simple pointer to their web site would have been sufficient.
I am sure they considered that, but they will have enough trouble with ineligibles wheedling copies and sending them in without posting it for the world to download.
I suppose they could have sent out a password-protected URL, but I can see where that might cause some problems as well.
> Ultimately it isn't a question of liability. I can't see how anyone with an > ounce of educated thought (american juries excluded, who knows what they think > about) could reasonably belive that gun manufactureers are actually liable.
In the case of rifles and shotguns, which have legitimate non-law-enforcement use, I would say you are correct. In the case of handguns, which don't have a legitimate non-law-enforcement use, I would say that is wrong.
I think the question is preponderance. If the tool is mostly useful for legitimate purposes *and* is only turned to illegitimate use by a user that clearly violates the spirit in which it is intended to be used, then the developer should not be held responsible. Ladders are the best example of this that I can think of; they cost 60% more than they should because of misguided product liability judgements.
In the case of WinNuke and handguns, the reasonable use is not mostly legitimate. The developer should bear a good deal of responsibility for their misuse.
> > It's unbelievable how many people are confused over this. > > Yes, it is. There are still people who recommend SCSI without further > investigation. > > > For example, let's say your system is trying to read data and do a write at > > the same time. > > No decent OS would do that. It would concentrate on reads and save the writes > for later, unless the write cache is full.
Unless you are doing a syslog operation, as most MTAs do, which syncs the disk. You can disable this in syslog.conf, of course, the biggest performance win I have seen for most mail systems.
> > > With IDE your OS has to issue one command to the controller which passes it > > to the device and then waits... > > With IDE maybe. With ATA not. ATA does have everything that SCSI has, and > more. Read the specs at www.t13.org.
Specs are specs. Real-world implementations? Widely available controllers? Systems with this in standard? Drivers that match? For multiple OSes?
> on the IDE v SCSI be careful. with some drives > the difference really is just a chip, but often > drive manufacturers will use different actuators and > such for SCSI drives (due to the fact that > they're more likely to be dropped into a > high-stress environment).
Actually I cannot believe no one has brought up the real difference between IDE and SCSCI:
-- Tagged command queueing
Where IDE drives fall down is their inability to process more than one command at once. Though I am out of the hardware game now, I do run both types of drives, and IDE still is very bad at multi-tasking.
SCSI drives can have multiple commands sent to them, and can disconnect and acknowledge the command. When the command is complete, the driver services it. You won't notice the difference until a server begins to get hard, then you will really notice the difference.
Actually, if it is mostly a mail machine, I wonder if you have made the best change I ever made to my mail server, a line in syslog.conf:
mail.* -/var/log/maillog
The dash preceding the file name indicates that syslog should not sync after every log entry. I don't mind the miniscule chance of losing a mail log message on a hard disk crash, and the performance difference when processing mail queues is huge.
Slashdot Mirror
The whole thing is a typo. Dell rates Windows and Linux the same for performance. Dell's editor and proofreader screwed up.
We must work in different worlds. In the Linux/Apache world I inhabit, serving a million hits a day on a single machine is no big deal. Up until early this year, I had a dual-processor 300MHz Linux box with 256M RAM that served 1.4 million, in addition to doing DNS and mail (over 30,000 messages per day). It's load average started going over 1 during peak time, so I moved it to an 850MHz Athlon.
Let's see -- you believe you can control a chemical in your body and what it does to you.
If cynicism is a disease, you appear to have it....
Yes, but you selected it by setting LD_LIBRARY_PATH. Not by overwriting the system version.....
Any time you can get a credit card number via a normal database query it is a security hole.
I will say it again -- anytime you can query your database and get a credit card number it is a security hole. If you are not saving the information to a non-internet connected system, or encrypting with strong encryption before writing it to disk, you are playing fast and loose with customer information.
The simple rule should be this -- an unencrypted credit card number should never be written to disk, not even for a moment.
I agree. I also accelerated the switchover of
my clients because of Verisign's spam.
The following companies also have root-signing
certificates in Navigator 4.7:
ABAecom (Am. Bankers Assn)
ANX Network
AT&T
Access America (DST)
American Express
BBN
BelSign
Canada Post Corp.
DST (provider to quite a few others)
E-Certify
Entrust (DST)
Equifax
GTE CyberTrust
GlobalSign
IBM
KEYWITNESS
MCI Mall
National Retail Federation (DST)
Novell (DST)
TC TrustCenter
UPS
United States Postal Service
Uptime Group
Anyone know whether any of these sell certs?
I use ALT-N to change between windows. Enlighenment allows you to change focus only in the current desktop, which is just what I want. I use CTRL- to move between desktops and ALT-P to return to the anchor desktop (those keys are relics of an old DOS window manager called Desqview).
Bottom line is I don't use my mouse except for web browsing; that is partly enabled by my choice of applications (vim, mutt, tin, ncftp, and xterm). I am starting to use StarOffice some (goodbye, Windoze!) and there I have to use the mouse a bit. But even then, once I am in the doc they have some pretty good key shortcuts.
> This little bit of mail ended up being nearly a
> megabyte with the attachments converted into base-64. )-:
A megabyte isn't what it used to be. 8-)
> A simple pointer to their web site would have been sufficient.
I am sure they considered that, but they will have enough trouble with
ineligibles wheedling copies and sending them in without posting it for the
world to download.
I suppose they could have sent out a password-protected URL,
but I can see where that might cause some problems as well.
> Ultimately it isn't a question of liability. I can't see how anyone with an
> ounce of educated thought (american juries excluded, who knows what they think
> about) could reasonably belive that gun manufactureers are actually liable.
In the case of rifles and shotguns, which have legitimate non-law-enforcement
use, I would say you are correct. In the case of handguns, which don't have
a legitimate non-law-enforcement use, I would say that is wrong.
I think the question is preponderance. If the tool is mostly useful for
legitimate purposes *and* is only turned to illegitimate use by a user that
clearly violates the spirit in which it is intended to be used, then the
developer should not be held responsible. Ladders are the best example of
this that I can think of; they cost 60% more than they should because of
misguided product liability judgements.
In the case of WinNuke and handguns, the reasonable use is not mostly legitimate.
The developer should bear a good deal of responsibility for their misuse.
Did anyone notice the guy saying:
"Why don't you reset just to make sure?"
They proceed to reboot the system and everything
goes to hell.
The funny thing is, I bet most Windows users
didn't notice anything out of the ordinary.
> > It's unbelievable how many people are confused over this.
>
> Yes, it is. There are still people who recommend SCSI without further
> investigation.
>
> > For example, let's say your system is trying to read data and do a write at
> > the same time.
>
> No decent OS would do that. It would concentrate on reads and save the writes
> for later, unless the write cache is full.
Unless you are doing a syslog operation, as most MTAs do, which syncs the disk.
You can disable this in syslog.conf, of course, the biggest performance win
I have seen for most mail systems.
>
> > With IDE your OS has to issue one command to the controller which passes it
> > to the device and then waits...
>
> With IDE maybe. With ATA not. ATA does have everything that SCSI has, and
> more. Read the specs at www.t13.org.
Specs are specs. Real-world implementations? Widely available controllers?
Systems with this in standard? Drivers that match? For multiple OSes?
> on the IDE v SCSI be careful. with some drives
> the difference really is just a chip, but often
> drive manufacturers will use different actuators and
> such for SCSI drives (due to the fact that
> they're more likely to be dropped into a
> high-stress environment).
Actually I cannot believe no one has brought up the real difference between IDE and SCSCI:
-- Tagged command queueing
Where IDE drives fall down is their inability to process more than one command at once. Though I am out of the hardware game now, I do run both types of drives, and IDE still is very bad at multi-tasking.
SCSI drives can have multiple commands sent to them, and can disconnect and acknowledge the command. When the command is complete, the driver services it. You won't notice the difference until a server begins to get hard, then you will really notice the difference.
Actually, if it is mostly a mail machine, I wonder if you have made the best change I ever made to my mail server, a line in syslog.conf:
mail.* -/var/log/maillog
The dash preceding the file name indicates that
syslog should not sync after every log entry. I
don't mind the miniscule chance of losing a mail
log message on a hard disk crash, and the performance difference when processing mail queues is huge.