Running it on port 443 is a better idea, because corporate proxies & things like Microsoft's ISA Server expect to see SSL-encrypted traffic on that port. They often disallow encrypted traffic on port 80.
For example, if you want all 100 columns from a table, 'SELECT *' works quite nicely. However, if you want all but 1 of the 100 columns, be prepared to spell out 99 column names.
If this is your main problem with SQL, then you have other problems as well. Who in their right mind needs a table with 100 columns? If you have 100 columns, you seriously need to normalize your database.
There's another problem here. Using 'SELECT *' is a really really really bad idea. The first reason that comes to mind is that many languages return recordsets with indexed columns, not named ones. This means that if some DBA you've never met sticks a column into the DB at the wrong spot, your application is now either crashing because of mismatched data types (I assume that if you use 'SELECT *' you don't bother to check these either) or displaying all kinds of ugliness.
Let's assume you are working with a language that indexes recordsets by fieldname instead of by numerical index. Now if a fieldname in the DB changes (not that this should happen), you have to touch your code wherever that field is used instead of making a one-line change to your SQL specifying the new name.
You also get the great performance benefits of retrieving all new fields added to the DB if they're added correctly to the end of the table. You know how fast your query was running before? Now let's also retrieve a 2MB BLOB with each record. Have fun figuring out why your application is suddenly performing like utter crap.
No more silly "select max(id) from my table" queries after you insert a record...
You don't actually do that, do you?
Please tell me you really query for the the exact data you just inserted with the addition of the id field, and aren't just crossing your fingers and hoping that somebody else didn't stick data into the table after your insert and before your select..
But what if you gained more in the amount saved than you paid in taxes?
If you gained more than you paid, it's because somebody else got the shaft and is paying for the benefits you're getting that you didn't fund yourself. Kudos to you for looking for ways to legislate somebody else into buying yours for you, but there still ain't no such thing as a free lunch.
Or what if you didn't actually have to pay anything extra in taxes, and the funds were just reallocated from, say, defense spending?
This is pure genius. Yes, let's take money away from our military so we can pay for -broadband-. Nobody really needs a military right now anyhow, right? If we need one sometime later on, we'll just materialise one out of the same orifice you got that free lunch from above.
Other countries have proved its possible, and that it works better for more people than the way America does it.
Other countries have proved they can offload the maintenance of security across most of the world onto another country that values its military and is willing to take on the burden of being the world's policeman. In a few select cases, they've shown that a well-armed populous in conjunction with harsh terrain and/or weather can bog down an invading army badly enough that the invaders might choose to reconsider. Your method only "works" if you define success as providing a bunch of services and completely ignore what happens when the fecal matter hits the rotary air circulation device. I bet if you asked most of Europe if defence spending should be valued around say, 1940, you might get a different answer than you do today.
Will you really be so foolish as to let ideology stand in opposition to demonstrated proof of benefit to your own person?
Demonstrated proof of benefit, eh? Sure, give my right hand a cookie while you chop off the left. You just gave me a benefit, right?
Taxes are the cost we pay for a civilized society.
Taxes are one of the costs we pay for government. A civilised society doesn't magically come along with that, no matter how many opiates you throw to the masses.
NANOG has been on fire with posts about this issue over the past few days. The following two from Leo Bicknell do a good job of explaining why this sort of thing would happen, why nobody in particular is The Bad Guy[tm], and why this issue has no relevance to the issue of internet resilience in the case of natural or manmade disaster:
There were a few talks at Black Hat this year regarding Oracle. I only attended one of them (Cesar Cerrudo's talk), but the presenter slammed Oracle pretty hard. If the tone of the others was even remotely similar, it wouldn't surprise me if somebody lit a fire under her ass, asking why everyone in the security community thinks Oracle sucks.
Sign up for a webhosting account over at Hurricane Electric. They include free torrent hosting. According to their torrent FAQ, they'll eventually limit you to 25 torrents per account, but their servers sit on fat pipes and they won't charge you for the bandwidth used.:)
FYI: I don't work for them or anything; I'm just a very pleased customer.
The telcos wanting something doesn't automatically make it bad. There are plenty of reasons to dislike muni wireless without even considering the impact on the telcos' bottom lines. Personally, I'm opposed to using tax dollars to pay for anybody's pet project that expands the power and responsibility of government. That includes projects I might benefit from as well as the skate park I'll never use.
If you want to do something cooperatively with your neighbours, why not form a co-op? Then you can show everybody how great a model it is, and you won't get folks like me bitching about you trying to raise my taxes for your pet project..
Given that many folks who use these devices work in financial services or other fields that deal with sensitive information, it's worth $Lots to them to ensure that nobody else can get ahold of their data. It's better for the data to be accidentally erased and restored from backup 10 times than for somebody else to gain access to it once.
We're not talking about a device which has Aunt Jane's need to keep track of her nieces' and nephews' birthdays as its primary purpose here..
Their deferral to the legislature for such a pointedly Constitutional issue is worrying. Everything I have to say about this was already said better in Justice O'Connor's and Justice Thomas's dissenting opinions though, so I'll just point folks there.
In most cases a database server will indeed boot faster then the entire server, but the opposite is also possible.
If your entire server goes down, the DB running on it does, too. Your recovery time is then however long it takes for your server's hardware and OS to come up plus the time the DB server needs.
A database server deserving it's name has to do a host of recovery operations. When you're unlucky and it either crashed, or was shut down immediately recovery can take hours
Sure, but it's -still- faster than also having to bring your OS back up. Granted, if power dropped from beneath your server, the DB recovery can be many times longer than the OS boot time. I'm having difficulty imagining a case where it'd be faster to reboot the entire server than it would to just cycle the DB server process, though. Comparing a "normal" full reboot with a DB recovery from a hard crash is comparing apples & oranges.
Here's the Cliff's Notes version for folks who want to know if the US troops screwed up:
It says the US troops didn't know the car with the Italians was coming, they did exactly what they were supposed to do according to their standard operating procedures, the car was moving at approximately twice the speed other cars usually do at that spot, and the car didn't slow down until after it had been shot.
It further says that only one American kinda-sorta had an idea something related to Sgrena might have been going on, but he was an aide to an Italian Major General who told him not to tell anybody about it.
What about building this into a UPS? Say you took a bunch of 1.5 volt cells and arranged them in series. Then you could take off from between any given pair depending on how much voltage each device required. You could charge them all at once with only a single pair of connections to the terminals at the extreme ends.
I'm envisioning something like this, assuming 1.5 volts per cell (should be obtainable with the right industrial deep-cycle batts):
[okay, that was anticlimactic. I just spent 10 minutes trying to get slashcode to take my ASCII art and failed miserably. Any ASCII art experts care to respond with tips on how to make it work?]
You could come within.75V or so of the input spec of any given device, which is probably within tolerances, and the deep-cycle batts should provide more than enough current. They'd also double as a handy-dandy UPS. You can charge the whole set from the ends, so charging is relatively easy.
Good summary. As long as you care about one set of benchmarks and don't give a damn about reliability, real-world performance, or whether the manufacturer will answer your phone calls when the magic smoke gets out of the adapter, go with those cards.
It's not like you'd set up redundant disks for reasons other than short-term performance, right?
(not trying to flame, merely to point out that there might be other things you'd consider before "recommending" a RAID adapter)
Oops--sorry. I was attempting to address 602(b) in my comment about the copy being legally made.
(b) In a case where the making of the copies or phonorecords would have constituted an infringement of copyright if this title had been applicable, their importation is prohibited. In a case where the copies or phonorecords were lawfully made, the United States Customs Service has no authority to prevent their importation unless the provisions of section 601 are applicable.
Since they were lawfully made in Russia, I thought 602(b) was satisfied. I wasn't aware that downloading touched upon reproduction but not importation. Thank you!
(2) importation, for the private use of the importer and not for distribution, by any person with respect to no more than one copy or phonorecord of any one work at any one time
I've been hesitant to buy from allofmp3.com for legal reasons, but it looks like purchasing in the US is okay as long as you don't download two copies of the same album at the same time. You meet the requirements of purchasing from an authorised distributor, etc since allofmp3.com has the appropriate licences in Russia. Have I missed something?
Your analysis is a bit lacking. The reason Access blows up is because it doesn't deal well with more than one user, and on top of that the MS Jet database engine they supply with it seems to cook itself once you get more than a few million records in a table. More hardware won't help.
Excel is another one that often starts small and grows to ginormous proportions. I've blown my share of buffers in Excel too, and again, the limitations are not in hardware. The software simply falls over and dies at a certain point.
People rewrite for DB2, Oracle, even MS SQL Server because Access and Excel can't cut it once you get past a certain point. Throwing more hardware at the problem will not help. Clustering is useless for the situation you described.
The update button showed up for me today. I clicked it and it ran me through the download and install of 1.0.1. The automatic update was intentionally delayed because of server capacity issues; apparently they've got them sorted out now.
Slashdot Mirror
If this was true anyone working in a UPS environment would be a sick nutter.
;)
Haven't met many sysadmins, have you?
Running it on port 443 is a better idea, because corporate proxies & things like Microsoft's ISA Server expect to see SSL-encrypted traffic on that port. They often disallow encrypted traffic on port 80.
For example, if you want all 100 columns from a table, 'SELECT *' works quite nicely. However, if you want all but 1 of the 100 columns, be prepared to spell out 99 column names.
If this is your main problem with SQL, then you have other problems as well. Who in their right mind needs a table with 100 columns? If you have 100 columns, you seriously need to normalize your database.
There's another problem here. Using 'SELECT *' is a really really really bad idea. The first reason that comes to mind is that many languages return recordsets with indexed columns, not named ones. This means that if some DBA you've never met sticks a column into the DB at the wrong spot, your application is now either crashing because of mismatched data types (I assume that if you use 'SELECT *' you don't bother to check these either) or displaying all kinds of ugliness.
Let's assume you are working with a language that indexes recordsets by fieldname instead of by numerical index. Now if a fieldname in the DB changes (not that this should happen), you have to touch your code wherever that field is used instead of making a one-line change to your SQL specifying the new name.
You also get the great performance benefits of retrieving all new fields added to the DB if they're added correctly to the end of the table. You know how fast your query was running before? Now let's also retrieve a 2MB BLOB with each record. Have fun figuring out why your application is suddenly performing like utter crap.
No more silly "select max(id) from my table" queries after you insert a record...
You don't actually do that, do you?
Please tell me you really query for the the exact data you just inserted with the addition of the id field, and aren't just crossing your fingers and hoping that somebody else didn't stick data into the table after your insert and before your select..
But what if you gained more in the amount saved than you paid in taxes?
If you gained more than you paid, it's because somebody else got the shaft and is paying for the benefits you're getting that you didn't fund yourself. Kudos to you for looking for ways to legislate somebody else into buying yours for you, but there still ain't no such thing as a free lunch.
Or what if you didn't actually have to pay anything extra in taxes, and the funds were just reallocated from, say, defense spending?
This is pure genius. Yes, let's take money away from our military so we can pay for -broadband-. Nobody really needs a military right now anyhow, right? If we need one sometime later on, we'll just materialise one out of the same orifice you got that free lunch from above.
Other countries have proved its possible, and that it works better for more people than the way America does it.
Other countries have proved they can offload the maintenance of security across most of the world onto another country that values its military and is willing to take on the burden of being the world's policeman. In a few select cases, they've shown that a well-armed populous in conjunction with harsh terrain and/or weather can bog down an invading army badly enough that the invaders might choose to reconsider. Your method only "works" if you define success as providing a bunch of services and completely ignore what happens when the fecal matter hits the rotary air circulation device. I bet if you asked most of Europe if defence spending should be valued around say, 1940, you might get a different answer than you do today.
Will you really be so foolish as to let ideology stand in opposition to demonstrated proof of benefit to your own person?
Demonstrated proof of benefit, eh? Sure, give my right hand a cookie while you chop off the left. You just gave me a benefit, right?
Taxes are the cost we pay for a civilized society.
Taxes are one of the costs we pay for government. A civilised society doesn't magically come along with that, no matter how many opiates you throw to the masses.
NANOG has been on fire with posts about this issue over the past few days. The following two from Leo Bicknell do a good job of explaining why this sort of thing would happen, why nobody in particular is The Bad Guy[tm], and why this issue has no relevance to the issue of internet resilience in the case of natural or manmade disaster:
. html. html
http://www.merit.edu/mail.archives/nanog/msg12302
http://www.merit.edu/mail.archives/nanog/msg12350
Am I missing something here?
:)
Yes.
Can we get our freedom back while we're there?
There were a few talks at Black Hat this year regarding Oracle. I only attended one of them (Cesar Cerrudo's talk), but the presenter slammed Oracle pretty hard. If the tone of the others was even remotely similar, it wouldn't surprise me if somebody lit a fire under her ass, asking why everyone in the security community thinks Oracle sucks.
Sign up for a webhosting account over at Hurricane Electric. They include free torrent hosting. According to their torrent FAQ, they'll eventually limit you to 25 torrents per account, but their servers sit on fat pipes and they won't charge you for the bandwidth used. :)
FYI: I don't work for them or anything; I'm just a very pleased customer.
The telcos wanting something doesn't automatically make it bad. There are plenty of reasons to dislike muni wireless without even considering the impact on the telcos' bottom lines. Personally, I'm opposed to using tax dollars to pay for anybody's pet project that expands the power and responsibility of government. That includes projects I might benefit from as well as the skate park I'll never use.
If you want to do something cooperatively with your neighbours, why not form a co-op? Then you can show everybody how great a model it is, and you won't get folks like me bitching about you trying to raise my taxes for your pet project..
Given that many folks who use these devices work in financial services or other fields that deal with sensitive information, it's worth $Lots to them to ensure that nobody else can get ahold of their data. It's better for the data to be accidentally erased and restored from backup 10 times than for somebody else to gain access to it once.
We're not talking about a device which has Aunt Jane's need to keep track of her nieces' and nephews' birthdays as its primary purpose here..
Their deferral to the legislature for such a pointedly Constitutional issue is worrying. Everything I have to say about this was already said better in Justice O'Connor's and Justice Thomas's dissenting opinions though, so I'll just point folks there.
Maybe you'd have better luck suggesting BSD, then. ;)
In most cases a database server will indeed boot faster then the entire server, but the opposite is also possible.
If your entire server goes down, the DB running on it does, too. Your recovery time is then however long it takes for your server's hardware and OS to come up plus the time the DB server needs.
A database server deserving it's name has to do a host of recovery operations. When you're unlucky and it either crashed, or was shut down immediately recovery can take hours
Sure, but it's -still- faster than also having to bring your OS back up. Granted, if power dropped from beneath your server, the DB recovery can be many times longer than the OS boot time. I'm having difficulty imagining a case where it'd be faster to reboot the entire server than it would to just cycle the DB server process, though. Comparing a "normal" full reboot with a DB recovery from a hard crash is comparing apples & oranges.
Here's the Cliff's Notes version for folks who want to know if the US troops screwed up:
It says the US troops didn't know the car with the Italians was coming, they did exactly what they were supposed to do according to their standard operating procedures, the car was moving at approximately twice the speed other cars usually do at that spot, and the car didn't slow down until after it had been shot.
It further says that only one American kinda-sorta had an idea something related to Sgrena might have been going on, but he was an aide to an Italian Major General who told him not to tell anybody about it.
What about building this into a UPS? Say you took a bunch of 1.5 volt cells and arranged them in series. Then you could take off from between any given pair depending on how much voltage each device required. You could charge them all at once with only a single pair of connections to the terminals at the extreme ends.
.75V or so of the input spec of any given device, which is probably within tolerances, and the deep-cycle batts should provide more than enough current. They'd also double as a handy-dandy UPS. You can charge the whole set from the ends, so charging is relatively easy.
I'm envisioning something like this, assuming 1.5 volts per cell (should be obtainable with the right industrial deep-cycle batts):
[okay, that was anticlimactic. I just spent 10 minutes trying to get slashcode to take my ASCII art and failed miserably. Any ASCII art experts care to respond with tips on how to make it work?]
You could come within
What's wrong with doing it this way?
I find these summary tables are the best place to start. For further breakdowns, you can hit up the detailed budget info here.
Last I checked, a DS3 was 45 mb/s. That'd give PBS 90 mb/s of bandwidth, if you're right about them having 2 of them.
The closest I've heard of is the Cray X1E, but even that only claims 147 TFLOPS.
Good summary. As long as you care about one set of benchmarks and don't give a damn about reliability, real-world performance, or whether the manufacturer will answer your phone calls when the magic smoke gets out of the adapter, go with those cards.
It's not like you'd set up redundant disks for reasons other than short-term performance, right?
(not trying to flame, merely to point out that there might be other things you'd consider before "recommending" a RAID adapter)
Oops--sorry. I was attempting to address 602(b) in my comment about the copy being legally made.
(b) In a case where the making of the copies or phonorecords would have constituted an infringement of copyright if this title had been applicable, their importation is prohibited. In a case where the copies or phonorecords were lawfully made, the United States Customs Service has no authority to prevent their importation unless the provisions of section 601 are applicable.
Since they were lawfully made in Russia, I thought 602(b) was satisfied. I wasn't aware that downloading touched upon reproduction but not importation. Thank you!
17 USC 602 explicitly excepts:
(2) importation, for the private use of the importer and not for distribution, by any person with respect to no more than one copy or phonorecord of any one work at any one time
I've been hesitant to buy from allofmp3.com for legal reasons, but it looks like purchasing in the US is okay as long as you don't download two copies of the same album at the same time. You meet the requirements of purchasing from an authorised distributor, etc since allofmp3.com has the appropriate licences in Russia. Have I missed something?
Your analysis is a bit lacking. The reason Access blows up is because it doesn't deal well with more than one user, and on top of that the MS Jet database engine they supply with it seems to cook itself once you get more than a few million records in a table. More hardware won't help.
Excel is another one that often starts small and grows to ginormous proportions. I've blown my share of buffers in Excel too, and again, the limitations are not in hardware. The software simply falls over and dies at a certain point.
People rewrite for DB2, Oracle, even MS SQL Server because Access and Excel can't cut it once you get past a certain point. Throwing more hardware at the problem will not help. Clustering is useless for the situation you described.
The update button showed up for me today. I clicked it and it ran me through the download and install of 1.0.1. The automatic update was intentionally delayed because of server capacity issues; apparently they've got them sorted out now.