No, actually, according to the SQL-92 standard, SELECT COUNT(1) should return the number of rows for which the value 1 is not null, which is equivalent to COUNT(*), the number of rows. The database does the exact same thing, possibly even more for a SELECT COUNT(1) if always-true assumptions were not made equivalent to COUNT(*) by the DBMS vendor. Most DBs would probably be able to further reduce execution time of the query, but how to go about doing that depends largely on which DB you use, how the tables are organized, etc... A "SELECT TOP 1 a.key FROM a WHERE a.key NOT IN (SELECT key FROM b)" should be faster, but it depends on the type of index and DB implementation, as counting a hash join of indices may be faster than actually retrieving the data for the first match.
I used the simpler SQL statement because I wanted to make a point, not give someone an optimized query for some imaginary database table.
Most of the time the DB isn't even accessible from the outside. Why worry about being rooted then ?
There's your answer... Most != All. The DB is connected to something, which is connected to something that is accessible from the outside. But attacks don't just happen from the outside, either. Probably 90% of the attacks you really need to be concerned about with most DB applications are an inside job. Can your company trust every user that has some access to the database?
Would you want to send 5 million rows to the application just to check a few fields in each of them, and how they relate to records before and after them? Hell no, sending 5 million rows uses a ton of bandwidth, even for small row sizes. Also, SQL is a language for set operations, while most (99%, Lisp/etc are other 1%) application languages are designed around a single value, not a set of values. For example: To check if array a[50000] is a subset of array b[2000000], in most languages, you must somehow iterate through both arrays (sorting would help, if possible) and see if each value in a (all 50000 of them) also exists somewhere in the 2 million values for b. In SQL, something like SELECT COUNT(*) FROM a WHERE a.key NOT IN (SELECT key FROM b) would do the same thing, only much faster than downloading 2,050,000 rows and comparing them. Each vendor handles internal set operations differently, but all of them optimize their internal data structures and abilities to do exactly these types of operations.
The other major issue is security. If your app has the ability to view tables in the database, then breaking your app, or finding the login and password your app uses compromises the entire system. It is much better to implement security policies in the database/stored procedures, and only allow users/apps to call stored procedures, possibly even using the procedures to validate login information on each procedure call. If someone managed to get the (non administrative) password to your database, would you rather have them be able to do anything they want (or even just view anything they want, such as credit card or health information), or have them only be able to do exactly what they were able to do without the password?
Especially if login information is used as a parameter (I always use username and password as parameters to look up access levels in all user-executable scripts for this reason), if the user cannot access a single table in your database, then they can only do what the stored procedures allow them to do. This allows you to have a central place where security logic is executed, and business logic may either be in the procedures (ideal), or in the app. Just remember, leaving business logic up to the app may pose a risk if the app has a flaw, if the procedures allow the user more access than the app does. If your database security model has more flaws than your app could, then maybe you should consider switching databases.
"It can, but most of the guys doing this are on salary, and would be reading slashdot getting paid if they weren't replacing a drive and getting paid."
Very true, except for the UPS issue. Seriously, I had 3 modems coming for some remote offices last week, one was lost, crushed, and delivered to the wrong address, and the other two were two days late.
True, but if Hyundai made hard drives, chances are they would all fail at the same time (about the computer equivalent of 24,000 miles), and it would be down. Besides, replacing drives costs money too, warranty or not, because it takes up your time, especially when UPS loses the replacements, crushes them, and then delivers them to the wrong address (at least, that's what they do with my replacement DSL modems).
Google doesn't host their data on RAM, just the server portions. When you do a query, they still have to check their (albeit advanced and highly parallel) database. Find me 3TB of NVRAM for less than $5,000, and you've got a sale. With simple DDR at about $120/GB, that will probably be difficult to do. Even if NVRAM were that cheap, that's still $360,000, which is a hell of a lot more than you want to spend to store your data.
Gamers? How many gamers really NEED large (>147GB) disks? SCSI drives are not produced for gamers, they are produced for business workstations and servers. I agree with you about SCSI being better, but the reasons you gave don't apply to all IDE controllers (number 1), and certainly not to all SATA controllers/disks (all reasons). A GOOD (i.e. usually not onboard, probably something from 3ware, etc.) SATA controller has a processor, command-queueing, separate, bi-directional channels for each device, and SATA connectors are designed for hot swapping (better than SCA actually, even to the point of connections being made in sequence due to staggered pins). I've got a 12-disk SATA RAID-5 array at work, and don't have any of the problems you listed, because I hand-picked the hardware to avoid those (and other) limitations. If you really want your games to run as fast as possible, then it's going to cost a few thousand dollars anyways, and if you really need that much space, maybe it'd be a good idea to buy a decent controller.
Higher-end controller cards (read: NOT IDE) can share a bus with another controller, allowing two systems (with a controller in each) to share access to a single (external) array, with dual power supplies, and technologies like SSA allow even the cabling to be redundant.
Of course, by the time you spent the money on this type of setup, you could probably have purchased another complete machine, with another array in it, and used software to handle redundancy and updates to the array. We did this with our SQL server setup. We have two machines with redundant power supplies and RAID-10 arrays, setup in a load-balancing cluster with one as an updating subscriber to the other (updates are sent between the machines real-time, losing about 10% on write performance, but doubling read performance). If you share the array between machines, you will save the 10% or so on write performance, but won't gain the read performance, so it all depends on your primary usage for the storage system. Of course, you can't completely avoid downtime (something WILL happen eventually), but by having a separate system, you can reduce the chances of having downtime, and reduce the length (since only one has to be up).
Some SATA RAID controllers do support the advanced features offered by high-end SCSI RAID controllers, it's just that it seems strange to spend $700 on a controller for $1000 in disks, vs. spending $500 on a controller for $4000 in disks. Most recent server boards support 133MHz PCI-X, so bandwidth to SCSI devices is not an issue. The difference is speed and quality. Still though, if you don't need the absolute fastest array (ours is about 610MB/sec read, 300MB/sec write, RAID-10 striped within, mirrored across channels), SATA is a good solution. We use 6 15k U320 SCSI disks for our primary database system (54GB total array size), and 12 7.2k 250GB SATA disks for our document imaging system (2TB, RAID-5 with hot spares). Sustained transfers from either array are practically identical, but the access times to the SCSI array is much lower (though this is partly due to differences between RAID levels, as having a RAID-10 array means that the closest stripe to the data can get priority). Either storage method easily outperforms Gb Ethernet, so the only real difference is the access times for processes performed on the local machines (such as index and data lookups for a database), and aside from a few ms difference in query time, which is usually much smaller than the running time for the query, a remote user can't tell the difference.
I believe that's related to a threading issue buried somewhere in the windows API. A similar issue happens when a background thread (like reading from a disk, network, etc) touches an object on another thread (like to change window contents). In certain cases, this moves the touched window to the background thread, which is a problem if the background thread is blocking for an interrupt (like waiting for disk or network I/O). One of those annoyances that have been around for years, and never got fixed, only to get covered up with more layers above it (i.e..NET).
Or, to make things simpler... If you really NEED true redundancy, having things in the same building is a problem. So either buy rack space at a colo, or run your redundant setup to another physical location, serviced by a different CO, preferably owned by a different company. Of course, then you need to be redundant as well, since you'll have to be in both places at once. (In other words, this solution requires two buildings, two carriers, and [at least] two sysadmins.) However, this may still be cheaper than actually having a long distance copper/fibre/microwave setup from a second CO, assuming that your company already has another building somewhere, and another sysadmin available there. But why go to the trouble of having redundant systems if you put them in the same place? One fire/lightning strike/power outage/flood/construction worker/etc. can take both links/systems down just as easily as one.
Have you worked in the US? They are already outsourcing jobs, do you seriously think he should quit to find the magical place you call a "company" that takes security seriously? Where is this place? Do they pay well? Company executives have a responsibility to focus on their core business, making a profit, etc., most started working before the letter "e" was prepended to every word in the language, and don't even know what the internet is, much less how important security is. They know buzzwords, sometimes, but there aren't many buzzwords to describe why you need to double your department's budget to focus on security.
The ones you've opened, like 135,137-139, and 445? You don't open ports in XP, you close them, the OS starts with all services enabled, all relative ports open. The ICF doesn't do anything about these ports, unless explicitly instructed to, and these are the ones that matter. NAT, or more accurately PAT (Port Address Translation), maintains the source and destination ports, just as a stateful firewall will, and makes the machine inaccessible to non-solicited ip/port combinations. This way, only the requests and responses to/from windows update/symantec/whoever are allowed to pass through, which is exactly how all home machines should always be, and exactly what is needed for a clean install. In addition, there have been vulnerabilities in the ICF itself, which will remain open until SP1 is installed. Host-based security is a nice addition to network security, but I would be very nervous having the machines I administer connected the internet with nothing more than ICF and an AV package, even though all of them are up to date on patches. There are more vulnerabilities out there, patches from Microsoft are far from pre-emptive, and signature-based (AV) software is reactive, often missing signatures until it is too late (someone had to get infected to get the signature).
Problem is, the Windows Firewall is almost completely useless, and the average computer is probably hit by an attack every 20 minutes, which is far less time than it takes to download all of the patches, especially since the first reboot will only cover SP1, which only eliminates about 5% of the active exploits. The original (I'm told the SP2 version is better) windows firewall does not protect people from any of the attack vectors I've seen coming through my network so far this year. It is a "stateful firewall", it's just that the only state it maintains is an open one. It does not protect the computer from access to system services (most notably RPC), so it cannot protect people for long enough to patch their systems. There are only two methods for a clean install, either install and patch offline from CDs, or install from behind a stateful firewall (either a cheap linksys/dlink/netgear type or your network firewall). All installations we do at work are done initially on the private segment of the network, with packets sent through a NATd portion of the firewall (which by the nature of NAT accomplishes exactly what is needed). Of course, we also drop packets which have no legitimate purpose on our network, and log the supposed legitimate ones, which is probably a bit beyond the requirements for installing XP on granny's computer.
Re:Don't use Promise...
on
SATA vs ATA?
·
· Score: 2, Informative
No, the PATA cards suffer from being PATA, performance is cut in half due to using the same channel, and the channel is limited to 100/133MB/sec transfer rate. Shouldn't be half, though, unless drives are fast enough to max out the interface speed (which they aren't, fastest 15K rpm SCSI drives are about 109MB/sec internal transfer).
I haven't experienced any issues like that, and can confirm that the hot-swap and hot-spare capabilities work as expected on the 9500-12. I have not performed any benchmarks on the system, but have not experienced any read/write delays, which is probably helped by the cache of the controller and drives. I have 12 250GB drives, a mirrored pair for the OS, and a 9 drive level 5 array, with one hot spare. Pull any drive, and the hot spare works correctly, and the missing drive is rebuilt when plugged back in. Works exactly like the Adaptec 7902/2010ZCR solution in our SCSI servers, except the drives are about half the speed.
The few complaints I've seen about the 3ware cards are very similar to what you've said, though, but seem to be limited to a few specific OS/software combinations, which leads me to believe that: a) Few people realize what impact specific RAID levels have on performance (e.g. RAID 5 requires reads from all disks during a write to calculate the parity information.), and how certain hardware may reduce that impact (or in the case of PATA, significantly increase the impact of that specific problem), and b) There is some sort of issue with a specific type of read being performed by NFS, either a filesystem driver problem, or a hardware driver problem, possibly both.
As a quick summary, the major problem with PATA cards is that they use the PATA interface, command set, and drives. For speed, each drive should have it's own channel. The benchmarks you gave suggest other problems as well, and the older (PCI/33) controllers may have bottlenecks at the bus, but the newer cards (PCI-X/133) eliminate that issue for PATA/SATA drives (since you shouldn't use either if speed is your primary concern). If you want CHEAP, LARGE, and RELIABLE storage, the 9500 works well. If you want FAST and RELIABLE, a dual-channel U320 Adaptec RAID card works wonders, and it's nice to hit 640MB/sec instantaneous transfer speeds, with actual continuous reads at almost 600MB/sec, and writes at about 280MB/sec (RAID 1+0, 6 15Krpm drives, mirrored across channels, striped within channels).
Re:Don't use Promise...
on
SATA vs ATA?
·
· Score: 2, Informative
Absolutely, we have a 3TB server I recently set up at work with a 3Ware 9500-12 SATA RAID card. The card is expensive (~$700), but well worth it, for the supported RAID levels, management software, drivers, and support that only 3Ware currently offer in this market.
Actually, it depends on what you are measuring. If you are measuring bits/sec of traffic vs. bytes/sec of data, the factor is probably around what you stated for smaller packets. Since this is typically how bps/Bps is measured, the numbers on the page of the site are quite possibly correct. Of course, the tech guy is still a moron, but the explanation is almost correct. Those extra bits get "stuck" when the packets are decoded, since the ethernet and TCP/IP headers will all be stripped off.
Expanding on this idea, why not patch bash to log all actions by users with uid 0, then create an account for each admin with uid 0. On some OSs, this may also require a kernel patch to hold the username as well as the uid, since I know that Linux used to store only the uid, and uses that to lookup the username (which will then resolve to the first matching entry), and do not know if this is still the case. If possible, you could also consider using and admin group (like wheel), but this may not be enough to get the job done.
Exactly, he says it's not about (discrete) mathematics, but when it comes down to what a programmer is supposed to do, it's all discrete math. You have a Turing machine (albeit limited), and the whole point is to do what needs to be done correctly and as efficiently as possible. Some things still need to be written the same way they were in "1985", unlike the author's view that optimal code doesn't matter.
Yes, machines are faster now, by at least an order of magnitude, but optimizing poor code can speed things up more than engineering a new processor. Bubble Sort a list of one billion points of data (O(n^2) compares = k * (1e18)) on a new 3GHz machine (assuming 1 compare per clock), and you need about 3.333e8 (333333333.33) seconds (about 10.5 years). Weak Heap (best), Quick, or Heap sort the same billion points (O(n*log n) compares = k * (~3e10)) on an old 486/33MHz (again assuming 1 compare per clock), and you need about 9.0909e3 (9090.909) seconds (about 2.5 hours).
There you go, the author can use the new Pentium 5s, and I guess the rest of us can go dig out our 486s. Sure, you don't often need to sort a billion records, but next time you do, make sure your algorithm is reasonable, then use a language that allows you to implement it. One-size-fits-all library, garbage collection, and run-time language error checking might be good for rapid development, but doing things efficiently requires lower-level interaction, sometimes even below what C allows. Bubble sort 2 records, and you won't see much benefit, but for performance critical sections of code, sometimes it's better to optimize first, then use comments to make it readable, than to write code that looks like comments. Even adding bounds checking to the sorts would at least double the time required, which in this case could mean anywhere from another 3 or 4 hours up to the time left until you collect social security.
Yeah, something like a Linux or FreeBSD machine with two NICs, one to your AP(s) and the other to your network. Set up PoPToP or IPSec on the machine, and have all clients use a username and password to connect to the VPN server. If you use PPTP (PoPToP) or IPSEC, virtually every client will be able to connect without additional software. If you do use PPTP though, and intend to use it for Windows clients, be sure to disable MSCHAPv1, and use only MSCHAPv2, since v1 is actually less secure than WEP. With the gateway server installed, you could even allow NATed connections to the internet (for clients in the board room, visiting, etc...), but deny access to the internal network to anyone not on the VPN. FreeBSD and Linux are both ideally suited to this sort of thing (I have a similar solution to this on a FreeBSD box at work).
Whatever you do, don't use hardware solutions. Ever had a flash update fail on a router? Try explaining why nobody can connect because the APs ROM is toasted, and that it will be three days before a new ROM comes in. Hardware security solutions have just as many errors (if not more) as software ones, but they are a hell of a lot worse to update. Don't trust them, and you likely won't have to deal with them. Also, sometimes it's best to go with a product that less well-known (i.e. NOT Cisco, Linksys, RealSecure (laughs), Internet Security Solutions (laughs again), Microsoft, Microsoft, Microsoft....), since you won't see an exploit that has 500,000 machines attacking your network within two hours of the release of the patch (or before). I have had to fix two security issues with my FreeBSD box since it went in, and only one required a 2 minute service outage (reboot).
Slashdot Mirror
No, actually, according to the SQL-92 standard, SELECT COUNT(1) should return the number of rows for which the value 1 is not null, which is equivalent to COUNT(*), the number of rows. The database does the exact same thing, possibly even more for a SELECT COUNT(1) if always-true assumptions were not made equivalent to COUNT(*) by the DBMS vendor. Most DBs would probably be able to further reduce execution time of the query, but how to go about doing that depends largely on which DB you use, how the tables are organized, etc... A "SELECT TOP 1 a.key FROM a WHERE a.key NOT IN (SELECT key FROM b)" should be faster, but it depends on the type of index and DB implementation, as counting a hash join of indices may be faster than actually retrieving the data for the first match.
I used the simpler SQL statement because I wanted to make a point, not give someone an optimized query for some imaginary database table.
Most of the time the DB isn't even accessible from the outside. Why worry about being rooted then ?
There's your answer... Most != All. The DB is connected to something, which is connected to something that is accessible from the outside. But attacks don't just happen from the outside, either. Probably 90% of the attacks you really need to be concerned about with most DB applications are an inside job. Can your company trust every user that has some access to the database?
Thank you, just to add a bit:
Would you want to send 5 million rows to the application just to check a few fields in each of them, and how they relate to records before and after them? Hell no, sending 5 million rows uses a ton of bandwidth, even for small row sizes. Also, SQL is a language for set operations, while most (99%, Lisp/etc are other 1%) application languages are designed around a single value, not a set of values. For example:
To check if array a[50000] is a subset of array b[2000000], in most languages, you must somehow iterate through both arrays (sorting would help, if possible) and see if each value in a (all 50000 of them) also exists somewhere in the 2 million values for b.
In SQL, something like SELECT COUNT(*) FROM a WHERE a.key NOT IN (SELECT key FROM b) would do the same thing, only much faster than downloading 2,050,000 rows and comparing them. Each vendor handles internal set operations differently, but all of them optimize their internal data structures and abilities to do exactly these types of operations.
The other major issue is security. If your app has the ability to view tables in the database, then breaking your app, or finding the login and password your app uses compromises the entire system. It is much better to implement security policies in the database/stored procedures, and only allow users/apps to call stored procedures, possibly even using the procedures to validate login information on each procedure call. If someone managed to get the (non administrative) password to your database, would you rather have them be able to do anything they want (or even just view anything they want, such as credit card or health information), or have them only be able to do exactly what they were able to do without the password?
Especially if login information is used as a parameter (I always use username and password as parameters to look up access levels in all user-executable scripts for this reason), if the user cannot access a single table in your database, then they can only do what the stored procedures allow them to do. This allows you to have a central place where security logic is executed, and business logic may either be in the procedures (ideal), or in the app. Just remember, leaving business logic up to the app may pose a risk if the app has a flaw, if the procedures allow the user more access than the app does. If your database security model has more flaws than your app could, then maybe you should consider switching databases.
"It can, but most of the guys doing this are on salary, and would be reading slashdot getting paid if they weren't replacing a drive and getting paid."
Very true, except for the UPS issue. Seriously, I had 3 modems coming for some remote offices last week, one was lost, crushed, and delivered to the wrong address, and the other two were two days late.
True, but if Hyundai made hard drives, chances are they would all fail at the same time (about the computer equivalent of 24,000 miles), and it would be down. Besides, replacing drives costs money too, warranty or not, because it takes up your time, especially when UPS loses the replacements, crushes them, and then delivers them to the wrong address (at least, that's what they do with my replacement DSL modems).
Google doesn't host their data on RAM, just the server portions. When you do a query, they still have to check their (albeit advanced and highly parallel) database. Find me 3TB of NVRAM for less than $5,000, and you've got a sale. With simple DDR at about $120/GB, that will probably be difficult to do. Even if NVRAM were that cheap, that's still $360,000, which is a hell of a lot more than you want to spend to store your data.
Hyundai's have great warranties, too, but you still have to walk if it's in the shop, whether it's covered by a warranty or not.
That is all, the rest is absolutely correct, except to mention that if you're running a Windows OS, the maximum volume size is 2.4TB anyway.
Gamers? How many gamers really NEED large (>147GB) disks? SCSI drives are not produced for gamers, they are produced for business workstations and servers. I agree with you about SCSI being better, but the reasons you gave don't apply to all IDE controllers (number 1), and certainly not to all SATA controllers/disks (all reasons). A GOOD (i.e. usually not onboard, probably something from 3ware, etc.) SATA controller has a processor, command-queueing, separate, bi-directional channels for each device, and SATA connectors are designed for hot swapping (better than SCA actually, even to the point of connections being made in sequence due to staggered pins). I've got a 12-disk SATA RAID-5 array at work, and don't have any of the problems you listed, because I hand-picked the hardware to avoid those (and other) limitations. If you really want your games to run as fast as possible, then it's going to cost a few thousand dollars anyways, and if you really need that much space, maybe it'd be a good idea to buy a decent controller.
Higher-end controller cards (read: NOT IDE) can share a bus with another controller, allowing two systems (with a controller in each) to share access to a single (external) array, with dual power supplies, and technologies like SSA allow even the cabling to be redundant.
Of course, by the time you spent the money on this type of setup, you could probably have purchased another complete machine, with another array in it, and used software to handle redundancy and updates to the array. We did this with our SQL server setup. We have two machines with redundant power supplies and RAID-10 arrays, setup in a load-balancing cluster with one as an updating subscriber to the other (updates are sent between the machines real-time, losing about 10% on write performance, but doubling read performance). If you share the array between machines, you will save the 10% or so on write performance, but won't gain the read performance, so it all depends on your primary usage for the storage system. Of course, you can't completely avoid downtime (something WILL happen eventually), but by having a separate system, you can reduce the chances of having downtime, and reduce the length (since only one has to be up).
Some SATA RAID controllers do support the advanced features offered by high-end SCSI RAID controllers, it's just that it seems strange to spend $700 on a controller for $1000 in disks, vs. spending $500 on a controller for $4000 in disks. Most recent server boards support 133MHz PCI-X, so bandwidth to SCSI devices is not an issue. The difference is speed and quality. Still though, if you don't need the absolute fastest array (ours is about 610MB/sec read, 300MB/sec write, RAID-10 striped within, mirrored across channels), SATA is a good solution. We use 6 15k U320 SCSI disks for our primary database system (54GB total array size), and 12 7.2k 250GB SATA disks for our document imaging system (2TB, RAID-5 with hot spares). Sustained transfers from either array are practically identical, but the access times to the SCSI array is much lower (though this is partly due to differences between RAID levels, as having a RAID-10 array means that the closest stripe to the data can get priority). Either storage method easily outperforms Gb Ethernet, so the only real difference is the access times for processes performed on the local machines (such as index and data lookups for a database), and aside from a few ms difference in query time, which is usually much smaller than the running time for the query, a remote user can't tell the difference.
I believe that's related to a threading issue buried somewhere in the windows API. A similar issue happens when a background thread (like reading from a disk, network, etc) touches an object on another thread (like to change window contents). In certain cases, this moves the touched window to the background thread, which is a problem if the background thread is blocking for an interrupt (like waiting for disk or network I/O). One of those annoyances that have been around for years, and never got fixed, only to get covered up with more layers above it (i.e. .NET).
Or, to make things simpler... If you really NEED true redundancy, having things in the same building is a problem. So either buy rack space at a colo, or run your redundant setup to another physical location, serviced by a different CO, preferably owned by a different company. Of course, then you need to be redundant as well, since you'll have to be in both places at once. (In other words, this solution requires two buildings, two carriers, and [at least] two sysadmins.) However, this may still be cheaper than actually having a long distance copper/fibre/microwave setup from a second CO, assuming that your company already has another building somewhere, and another sysadmin available there. But why go to the trouble of having redundant systems if you put them in the same place? One fire/lightning strike/power outage/flood/construction worker/etc. can take both links/systems down just as easily as one.
Well, it is "News for Nerds." Which implies that there is something "New" here, so yeah, probably around 30 at any given time.
Have you worked in the US? They are already outsourcing jobs, do you seriously think he should quit to find the magical place you call a "company" that takes security seriously? Where is this place? Do they pay well? Company executives have a responsibility to focus on their core business, making a profit, etc., most started working before the letter "e" was prepended to every word in the language, and don't even know what the internet is, much less how important security is. They know buzzwords, sometimes, but there aren't many buzzwords to describe why you need to double your department's budget to focus on security.
The ones you've opened, like 135,137-139, and 445? You don't open ports in XP, you close them, the OS starts with all services enabled, all relative ports open. The ICF doesn't do anything about these ports, unless explicitly instructed to, and these are the ones that matter. NAT, or more accurately PAT (Port Address Translation), maintains the source and destination ports, just as a stateful firewall will, and makes the machine inaccessible to non-solicited ip/port combinations. This way, only the requests and responses to/from windows update/symantec/whoever are allowed to pass through, which is exactly how all home machines should always be, and exactly what is needed for a clean install. In addition, there have been vulnerabilities in the ICF itself, which will remain open until SP1 is installed. Host-based security is a nice addition to network security, but I would be very nervous having the machines I administer connected the internet with nothing more than ICF and an AV package, even though all of them are up to date on patches. There are more vulnerabilities out there, patches from Microsoft are far from pre-emptive, and signature-based (AV) software is reactive, often missing signatures until it is too late (someone had to get infected to get the signature).
Problem is, the Windows Firewall is almost completely useless, and the average computer is probably hit by an attack every 20 minutes, which is far less time than it takes to download all of the patches, especially since the first reboot will only cover SP1, which only eliminates about 5% of the active exploits. The original (I'm told the SP2 version is better) windows firewall does not protect people from any of the attack vectors I've seen coming through my network so far this year. It is a "stateful firewall", it's just that the only state it maintains is an open one. It does not protect the computer from access to system services (most notably RPC), so it cannot protect people for long enough to patch their systems. There are only two methods for a clean install, either install and patch offline from CDs, or install from behind a stateful firewall (either a cheap linksys/dlink/netgear type or your network firewall). All installations we do at work are done initially on the private segment of the network, with packets sent through a NATd portion of the firewall (which by the nature of NAT accomplishes exactly what is needed). Of course, we also drop packets which have no legitimate purpose on our network, and log the supposed legitimate ones, which is probably a bit beyond the requirements for installing XP on granny's computer.
No, the PATA cards suffer from being PATA, performance is cut in half due to using the same channel, and the channel is limited to 100/133MB/sec transfer rate. Shouldn't be half, though, unless drives are fast enough to max out the interface speed (which they aren't, fastest 15K rpm SCSI drives are about 109MB/sec internal transfer).
I haven't experienced any issues like that, and can confirm that the hot-swap and hot-spare capabilities work as expected on the 9500-12. I have not performed any benchmarks on the system, but have not experienced any read/write delays, which is probably helped by the cache of the controller and drives. I have 12 250GB drives, a mirrored pair for the OS, and a 9 drive level 5 array, with one hot spare. Pull any drive, and the hot spare works correctly, and the missing drive is rebuilt when plugged back in. Works exactly like the Adaptec 7902/2010ZCR solution in our SCSI servers, except the drives are about half the speed.
The few complaints I've seen about the 3ware cards are very similar to what you've said, though, but seem to be limited to a few specific OS/software combinations, which leads me to believe that: a) Few people realize what impact specific RAID levels have on performance (e.g. RAID 5 requires reads from all disks during a write to calculate the parity information.), and how certain hardware may reduce that impact (or in the case of PATA, significantly increase the impact of that specific problem), and b) There is some sort of issue with a specific type of read being performed by NFS, either a filesystem driver problem, or a hardware driver problem, possibly both.
As a quick summary, the major problem with PATA cards is that they use the PATA interface, command set, and drives. For speed, each drive should have it's own channel. The benchmarks you gave suggest other problems as well, and the older (PCI/33) controllers may have bottlenecks at the bus, but the newer cards (PCI-X/133) eliminate that issue for PATA/SATA drives (since you shouldn't use either if speed is your primary concern). If you want CHEAP, LARGE, and RELIABLE storage, the 9500 works well. If you want FAST and RELIABLE, a dual-channel U320 Adaptec RAID card works wonders, and it's nice to hit 640MB/sec instantaneous transfer speeds, with actual continuous reads at almost 600MB/sec, and writes at about 280MB/sec (RAID 1+0, 6 15Krpm drives, mirrored across channels, striped within channels).
Absolutely, we have a 3TB server I recently set up at work with a 3Ware 9500-12 SATA RAID card. The card is expensive (~$700), but well worth it, for the supported RAID levels, management software, drivers, and support that only 3Ware currently offer in this market.
Don't forget, the latest 5.x release was 5.2.1, which followed 5.2[.0], so the lower values do exist, they just aren't used often.
Actually, it depends on what you are measuring. If you are measuring bits/sec of traffic vs. bytes/sec of data, the factor is probably around what you stated for smaller packets. Since this is typically how bps/Bps is measured, the numbers on the page of the site are quite possibly correct. Of course, the tech guy is still a moron, but the explanation is almost correct. Those extra bits get "stuck" when the packets are decoded, since the ethernet and TCP/IP headers will all be stripped off.
Expanding on this idea, why not patch bash to log all actions by users with uid 0, then create an account for each admin with uid 0. On some OSs, this may also require a kernel patch to hold the username as well as the uid, since I know that Linux used to store only the uid, and uses that to lookup the username (which will then resolve to the first matching entry), and do not know if this is still the case. If possible, you could also consider using and admin group (like wheel), but this may not be enough to get the job done.
Exactly, he says it's not about (discrete) mathematics, but when it comes down to what a programmer is supposed to do, it's all discrete math. You have a Turing machine (albeit limited), and the whole point is to do what needs to be done correctly and as efficiently as possible. Some things still need to be written the same way they were in "1985", unlike the author's view that optimal code doesn't matter.
Yes, machines are faster now, by at least an order of magnitude, but optimizing poor code can speed things up more than engineering a new processor.
Bubble Sort a list of one billion points of data (O(n^2) compares = k * (1e18)) on a new 3GHz machine (assuming 1 compare per clock), and you need about 3.333e8 (333333333.33) seconds (about 10.5 years).
Weak Heap (best), Quick, or Heap sort the same billion points (O(n*log n) compares = k * (~3e10)) on an old 486/33MHz (again assuming 1 compare per clock), and you need about 9.0909e3 (9090.909) seconds (about 2.5 hours).
There you go, the author can use the new Pentium 5s, and I guess the rest of us can go dig out our 486s. Sure, you don't often need to sort a billion records, but next time you do, make sure your algorithm is reasonable, then use a language that allows you to implement it. One-size-fits-all library, garbage collection, and run-time language error checking might be good for rapid development, but doing things efficiently requires lower-level interaction, sometimes even below what C allows. Bubble sort 2 records, and you won't see much benefit, but for performance critical sections of code, sometimes it's better to optimize first, then use comments to make it readable, than to write code that looks like comments. Even adding bounds checking to the sorts would at least double the time required, which in this case could mean anywhere from another 3 or 4 hours up to the time left until you collect social security.
Well put, if only more people on slashdot could understand what you wrote...
Yeah, something like a Linux or FreeBSD machine with two NICs, one to your AP(s) and the other to your network. Set up PoPToP or IPSec on the machine, and have all clients use a username and password to connect to the VPN server. If you use PPTP (PoPToP) or IPSEC, virtually every client will be able to connect without additional software. If you do use PPTP though, and intend to use it for Windows clients, be sure to disable MSCHAPv1, and use only MSCHAPv2, since v1 is actually less secure than WEP. With the gateway server installed, you could even allow NATed connections to the internet (for clients in the board room, visiting, etc...), but deny access to the internal network to anyone not on the VPN. FreeBSD and Linux are both ideally suited to this sort of thing (I have a similar solution to this on a FreeBSD box at work).
Whatever you do, don't use hardware solutions. Ever had a flash update fail on a router? Try explaining why nobody can connect because the APs ROM is toasted, and that it will be three days before a new ROM comes in. Hardware security solutions have just as many errors (if not more) as software ones, but they are a hell of a lot worse to update. Don't trust them, and you likely won't have to deal with them. Also, sometimes it's best to go with a product that less well-known (i.e. NOT Cisco, Linksys, RealSecure (laughs), Internet Security Solutions (laughs again), Microsoft, Microsoft, Microsoft....), since you won't see an exploit that has 500,000 machines attacking your network within two hours of the release of the patch (or before). I have had to fix two security issues with my FreeBSD box since it went in, and only one required a 2 minute service outage (reboot).