The easiest way to prevent this, in Maine at least, is to notify the phone company that no one except you can change your long distance carrier. After going through a slam, the local phone company let me know that I can freeze my long distance carrier, and only by my personal, verbal approval will they every change my long distance carrier.
Four years later, I get no phone telmarketer calls at all.
I hear this question a lot, and I am really tired of it. It doesn't matter how big the database is, but how much it is going to be used. If I created a multi-terabyte database (can you say p0rn?) that only had one user, sure Linux/Intel could handle it. But throw it up onto a network with millions of requests per hour, and the equation shifts. Could you build an Lintel box to support it?? Lets see....
Here are the priority items for any database box --
Memory. Databases love memory for cache, logs, etc. If you can keep your entire database in memory, disk speed becomes irrelevant after the first data access and for writes. If your box only supports a couple of gigs of memory, move on. We have boxes with 4GB of memory, and our DBA wants more.
Disk Bandwidth. The more disk bandwidth the better. Several little disks scattered about multiple SCSI controllers will usually perform better than comperable aggregated large disks. Don't even think about using IDE/EIDE
IO Speed. The faster your disks, the better (Duh...) Again, disk size can play second fiddle to disk access times. I would rather have many small, fast disk drives than one large, slow one.
CPU speed. Did you notice this was last??? Face it, if you can't keep it in memory and your disks aren't fast enough for your processor(s), then the CPU speed isn't as relevent
Network bandwidth. Most computers do not have issues here. However, there is overhead pushing data over a network, and the more data you push, the need for network bandwidth increases to respond to requests.
It is also a good idea to seperate application/web servers from database servers. All modern databases support the ability to service database requests over a network. Providing a unique network solely for database activity that is seperate from the user network is common in most shops now to support the data movement from database servers to the app servers.
The game all sys admins and DBAs perform is finding the current bottleneck. There is always a limiting factor for performance, and it can usually be tied to one of the above items
Determining a configuration to support a database is not easy. You need to gather usage predictions, such as number of concurrent users, read rates, update rates, log projections, and make a guess. You also need to know your target audience and how they access it. A million requests spread over 24 hours is not the same as a million requests in a short period.
For instance, without my glasses, I have 20/15 near vision because my retina is very sensitive. However, my far vision is 20/200 because my eyeball is football shaped and cannot properly focus.
All we can do with external optics is improve the ability to focus or magnify an image. The former is done with glasses, but, as mentioned in the article, can be improved up to the point of the retina's ability to resolve an image. The latter will provide super-human vision (microscopic/telscopic) but at the cost of tunnel vision and the loss of overall field of view.
Now, heat vision and x-ray vision are another matter.....
Alright... MI, the original, used sex. For instance (forgive the lack of actor names, I'm not into that kind of memorization). Just today, I say the episode where they melt the gold the bad army general has. They use sex to mis-direct him so they can switch his bullets with blanks.
Let's talk about some of the merits of MI:2
When the bad guy empties his clip into Ethan Hunt, we don't see gobs-of-goo. Yea...there were tons of people getting kicked and killed, but at least the gore level was low
The flaminco dance/seduction scene was imaginative
Loved the motorcycle chase scene. The gymnatics and jousting bits were well staged.
Even though there was some serious clevage/seduction scene, no nudity. While I would have loved a shot of some bare skin, it was not necessary for the movie (as it is rarely actually needed... let's just get the teens into the theater.)
I will have to admit, there were several times when I 'saw it coming'. But I still enjoyed it.
Keep repeating to yourself 'it's only a movie, it's only a movie', and enjoy a movie for what it is for a change.
There is definatly merit is using plain text-editor tools (long live vi!!!). I have been coding since the late 70's and have done assembler, basic, cobol, C, C++, Java, PERL, HTML, etc. using the various editors on each system.
I have also used a few different IDE's for C, C++, and most recently Java and HTML. What was the most frustrating with each new language was trying to learn the IDE's or, in the case of C++ and Java, the GUI interfaces. However, when coding applications that require a terminal GUI interface (like Windoze or X), the IDE's definatly have an advantage over text based systems.
Do I like IDE's?? No. Do I use them?? When I have to. I agree with the comment that using an IDE to manage hundreds of modules and lines of code makes a lot of sense. It can also make working on unfamiliar code easier. However, in my environments, this has rarely been necessary, coming from smaller shops.
I have become a large fan of vi (please, let's not fight...) because I now work on only Unix/Linux systems and have had the opportunity over the last several years to learn its nuances. Plus, as was also pointed out, I can depend on it being on every single Unix/Linux system I work on, unlike the most recent IDE fad, or even Emacs. This is not meant to say Emacs or IDE's are not valid, just not in my particular instance, especially since this is my 6th job in about the last 10 years. I need to be comfortable with a universal tool.
There is one last point I would like to make. I type 70 words/minute (of which at least 30 are correct.) I find mouse-based IDE's extremely irritating. IDE's that make use of the mouse, but also incorporate significate keyboard-shortcuts, get my vote.
The easiest way to prevent this, in Maine at least, is to notify the phone company that no one except you can change your long distance carrier. After going through a slam, the local phone company let me know that I can freeze my long distance carrier, and only by my personal, verbal approval will they every change my long distance carrier.
Four years later, I get no phone telmarketer calls at all.
I win.......
- Sun E450 dual CPU w/1 GB memory 2 18GB drives - around 30K (mirroring supported by OS)
- HP LC2000 dual CPU (700Mhz) w/1GB memory 4 18GB drives and HP Netraid board - $25K
Yep -- big boxes, if either Sun or Intel based, cost big bucks.....BTW - Linux runs great on the HP server (install time - 15 minutes, 1 reboot). Haven't tried it on the Sun box...
Here are the priority items for any database box --
- Memory. Databases love memory for cache, logs, etc. If you can keep your entire database in memory, disk speed becomes irrelevant after the first data access and for writes. If your box only supports a couple of gigs of memory, move on. We have boxes with 4GB of memory, and our DBA wants more.
- Disk Bandwidth. The more disk bandwidth the better. Several little disks scattered about multiple SCSI controllers will usually perform better than comperable aggregated large disks. Don't even think about using IDE/EIDE
- IO Speed. The faster your disks, the better (Duh...) Again, disk size can play second fiddle to disk access times. I would rather have many small, fast disk drives than one large, slow one.
- CPU speed. Did you notice this was last??? Face it, if you can't keep it in memory and your disks aren't fast enough for your processor(s), then the CPU speed isn't as relevent
- Network bandwidth. Most computers do not have issues here. However, there is overhead pushing data over a network, and the more data you push, the need for network bandwidth increases to respond to requests.
It is also a good idea to seperate application/web servers from database servers. All modern databases support the ability to service database requests over a network. Providing a unique network solely for database activity that is seperate from the user network is common in most shops now to support the data movement from database servers to the app servers.The game all sys admins and DBAs perform is finding the current bottleneck. There is always a limiting factor for performance, and it can usually be tied to one of the above items
Determining a configuration to support a database is not easy. You need to gather usage predictions, such as number of concurrent users, read rates, update rates, log projections, and make a guess. You also need to know your target audience and how they access it. A million requests spread over 24 hours is not the same as a million requests in a short period.
This is only a sig, this is only a sig.....
- The ability of the lens to focus
- The opacity of the lens
- The degree the retina can resolve
For instance, without my glasses, I have 20/15 near vision because my retina is very sensitive. However, my far vision is 20/200 because my eyeball is football shaped and cannot properly focus.All we can do with external optics is improve the ability to focus or magnify an image. The former is done with glasses, but, as mentioned in the article, can be improved up to the point of the retina's ability to resolve an image. The latter will provide super-human vision (microscopic/telscopic) but at the cost of tunnel vision and the loss of overall field of view.
Now, heat vision and x-ray vision are another matter.....
Let's talk about some of the merits of MI:2
- When the bad guy empties his clip into Ethan Hunt, we don't see gobs-of-goo. Yea...there were tons of people getting kicked and killed, but at least the gore level was low
- The flaminco dance/seduction scene was imaginative
- Loved the motorcycle chase scene. The gymnatics and jousting bits were well staged.
- Even though there was some serious clevage/seduction scene, no nudity. While I would have loved a shot of some bare skin, it was not necessary for the movie (as it is rarely actually needed
... let's just get the teens into the theater.)
I will have to admit, there were several times when I 'saw it coming'. But I still enjoyed it.Keep repeating to yourself 'it's only a movie, it's only a movie', and enjoy a movie for what it is for a change.
There is definatly merit is using plain text-editor tools (long live vi!!!). I have been coding since the late 70's and have done assembler, basic, cobol, C, C++, Java, PERL, HTML, etc. using the various editors on each system.
...) because I now work on only Unix/Linux systems and have had the opportunity over the last several years to learn its nuances. Plus, as was also pointed out, I can depend on it being on every single Unix/Linux system I work on, unlike the most recent IDE fad, or even Emacs. This is not meant to say Emacs or IDE's are not valid, just not in my particular instance, especially since this is my 6th job in about the last 10 years. I need to be comfortable with a universal tool.
I have also used a few different IDE's for C, C++, and most recently Java and HTML. What was the most frustrating with each new language was trying to learn the IDE's or, in the case of C++ and Java, the GUI interfaces. However, when coding applications that require a terminal GUI interface (like Windoze or X), the IDE's definatly have an advantage over text based systems.
Do I like IDE's?? No. Do I use them?? When I have to. I agree with the comment that using an IDE to manage hundreds of modules and lines of code makes a lot of sense. It can also make working on unfamiliar code easier. However, in my environments, this has rarely been necessary, coming from smaller shops.
I have become a large fan of vi (please, let's not fight
There is one last point I would like to make. I type 70 words/minute (of which at least 30 are correct.) I find mouse-based IDE's extremely irritating. IDE's that make use of the mouse, but also incorporate significate keyboard-shortcuts, get my vote.
Well.... duh.... I can't think of any use of a .god domain other than abuse. Which is exactly why I will rush out to get mine -- isno.god
After seeing Tammy Baker, I thank god I'm an athiest.