DDT was banned when? 1972. It takes how long to break down? 15 years. If DDT were the source of egg-shell thinning we would have seen an increase in egg shell thickness around 1987.
In just about every study on DDT/DDE you will note that DDT wasn't the only artifical compound found. It was usually accompanied by high concentrations of PCBs, mercury, and/or lead.
I can't tell you how many technical arguments I've seemed to "lose" because soley because I'm and "idiot." Double points if the first word in the comment is idiot. Triple points if in the process of calling you an idiot, they don't actually mention any new points, but merely repeat their previous troll.
You don't use Postgres for banking either. You use an AS/400 (oops dating myself) an iSeries running DB2. My payroll check hopps along every other week like clockwork over a 19200 line between my work's mini and the bank's mainframe, using protocols developed in the 80s.
Web databases, as seriously as we try to take them, are ALL toy databases.
Who said anything about "easier". The key word is predictable. I really can't vouch for the quality or lack there of in any open source project.
I can vouch for having been burned after an upgrade changes the behavior of a routine that worked happily for years.
Really, my "atomic transaction" code is about 300 lines of incr TCL. But it works, it allows me to cache common searches, and it is performance tuned to EXACTLY what my application needs.
Why in the hell did you write 250k line of database dependent code?
Let's see... I had a need, I had a volume of data...
Actually the artitecture is portable, but a lot of the reports use mysql specific math functions, and the web content uses full-text searching.
It would be perfectly reasonable to extend our classes to include PostGres support. There is already a module for MS-SQL, and sqlite. (Though I haven't tested them in years.)
My indigination was over being called an idiot for deigning to design a system back when performance was important and PostGres was not-quite-ready for prime time.
Actually I have. The problem is that sqllite doesn't behave well on NFS volumes. My application is also multi-threaded so session tables that get hit for reads and writes a lot have a tendency to trip over each other at odd spots.
I did write my interface code in a way that I could swap out MySQL for sqlite (or postgres, MS-SQL, or Oracle) at the drop of a hat. I've actually tested it with quite a few different database engines.
The problem you run into is breadth vs. depth. In applications that shoot for breadth, MySQL gives you a lot of performance while requiring very little customization.
And I'll also cheerfully explain over a few drinks about the fact that when your application's cheif function is to syncronize data between several backends (not to mention SMTP, flat files, and XML), you really can't rely on any one vendor's parlor tricks.
Please tell me how to implement atomic transactions and stored procedures in TCL.
It's called object oriented programming. Nothing in the code talks directly to the database, everyone passes through an abassador class. The ambassador class handles caching, deadlock avoidance, and locking. Yes Virginia, in a multi-threaded environment there is more than one stratagy for these things.
Stored procedures are a bad toy.
Please tell me how you reliably guard against SQL injection attacks using TCL.
SQL injection attacks? What, do you pass queries directly through a web form? Now that is silly.
Our application suite implements access control lists that lock objects down to the record. You don't issue a "SELECT..." statement in SQL, you perform the RecordLoad method in the container. You don't issue "UPDATE.." or "INSERT..." statements, you call the RecordSave or RecordWrite method.
You can perform queries. But the filter regexps for funny business before the command is run.
It's not that I "refuse" to learn anything else. It's that 3 years ago when I started my project I needed replication THEN. I needed a windows port THEN. I needed TCL bindings THEN. And I'm not going to re-write 250,000 lines of code because someone tells me my perfectly working system is inferior.
And you guys are yelling awful loud to have anything meaninful to say.
Could you defend you position that you did not want to distribute a program by branding the souce code and binaries with warning like "FOR INTERNAL USE ONLY -- DO NOT DISTRIBUTE"?
You've obviously never worked on a classified project.
As one of those sickos: yes I would actually pay money to use MySQL. In high-volume web transactions speed is everything, and you trust your backend to do nothing.
I get around most of mySQL's "limitations" in TCL.
Is Linux truly a modern OS? Let's be realistic here.
Very true. It's at least 3 years ahead of the state of the art in performance and theory. Unfortunately they are also 3 years ahead of the state of the art when it comes to driver support...
I can't believe that anybody is dumb enough to sign their contract.
Enter the joke about my brother... THE BUISNESS MAJOR.
Phone Call: Hey Sean, I just got a health club membership, can you read over the fine print?
(Two hours later, over a couple of bears)
Me: And this line item is where you are essentially financing a non-refundable $1500 "membership application" over 12 months at an ungodly interest rate.
Brother: Well I guess I stepped in it this time.
(Keep in mind, his major was business. I'm an engineering drop out.)
To make a long story short: any link is statistically insignifigant. What elevated cancer risks were found couldn't rule out other causes from chemicals, lifestyles, or location.
Before you fly off the handle about DDT, it's never been a health hazard to humans, and follow studies of egg shell thinning found that the concentrations required to thin eggs that severely isn't found in nature.
It turns out that lead, oil, and mercury were far more likely to have been the culprit. Each of those contaninates DID have a profound and immediate effect on the animals tested.
Mr. Happy and the twins will snap back. Worst case, they just need a few months away from the heat if you plan to spawn. I'm as bad as they come when it comes to wireless gear. I've worn a digital phone since 1997. My wife and I had a healthy baby girl last November. We thought it would take a few months of trying.
We are exposed to far greater amounts of EM radiation from the sun, in all sorts of unfilitered frequencies. And we have been since before man really groked that it rose every day and set every night.
I might also add that radio operators have been using very high powered equipment for more than a century. There is only one nasty effect from working around microwaves: male sterility if you are dumb enough to stand in front of a microwave tower to keep warm. And the problem there isn't the EM radiation. It's the fact that male testes don't like heat.
Slashdot Mirror
Don't laugh. Our CEO's laptop (XP SP1) started blue screening with 0x0000008E the day SP2 came out.
Bugs are generally the "undocumented features."
DDT was banned when? 1972. It takes how long to break down? 15 years. If DDT were the source of egg-shell thinning we would have seen an increase in egg shell thickness around 1987.
We didn't.
2003 USDA study, DDT/DDE concentrations are not linked to shell breakage in condors
1998 - Science News - Shell thinning in birds predates DDT.
In just about every study on DDT/DDE you will note that DDT wasn't the only artifical compound found. It was usually accompanied by high concentrations of PCBs, mercury, and/or lead.
I can't tell you how many technical arguments I've seemed to "lose" because soley because I'm and "idiot." Double points if the first word in the comment is idiot. Triple points if in the process of calling you an idiot, they don't actually mention any new points, but merely repeat their previous troll.
Bears? No I meant BEERS!
Web databases, as seriously as we try to take them, are ALL toy databases.
What's wrong with this picture?
Who said anything about "easier". The key word is predictable. I really can't vouch for the quality or lack there of in any open source project.
I can vouch for having been burned after an upgrade changes the behavior of a routine that worked happily for years.
Really, my "atomic transaction" code is about 300 lines of incr TCL. But it works, it allows me to cache common searches, and it is performance tuned to EXACTLY what my application needs.
Rule 2: It's not a data store. It's a non-volitile cache between the application code and the backup tape.
Rule 3: All software sucks. You plan for it to fail. You EXPECT dropped indexes, bad sectors, and id10t db managers who "DELETE FROM $TABLE".
Let's see... I had a need, I had a volume of data...
Actually the artitecture is portable, but a lot of the reports use mysql specific math functions, and the web content uses full-text searching.
It would be perfectly reasonable to extend our classes to include PostGres support. There is already a module for MS-SQL, and sqlite. (Though I haven't tested them in years.)
My indigination was over being called an idiot for deigning to design a system back when performance was important and PostGres was not-quite-ready for prime time.
I did write my interface code in a way that I could swap out MySQL for sqlite (or postgres, MS-SQL, or Oracle) at the drop of a hat. I've actually tested it with quite a few different database engines.
The problem you run into is breadth vs. depth. In applications that shoot for breadth, MySQL gives you a lot of performance while requiring very little customization.
(I still have a warm spot for sqlite though.)
I'll just keep getting paid to do what I do.
And I'll also cheerfully explain over a few drinks about the fact that when your application's cheif function is to syncronize data between several backends (not to mention SMTP, flat files, and XML), you really can't rely on any one vendor's parlor tricks.
It's called object oriented programming. Nothing in the code talks directly to the database, everyone passes through an abassador class. The ambassador class handles caching, deadlock avoidance, and locking. Yes Virginia, in a multi-threaded environment there is more than one stratagy for these things.
Stored procedures are a bad toy.
Please tell me how you reliably guard against SQL injection attacks using TCL.
SQL injection attacks? What, do you pass queries directly through a web form? Now that is silly.
Our application suite implements access control lists that lock objects down to the record. You don't issue a "SELECT..." statement in SQL, you perform the RecordLoad method in the container. You don't issue "UPDATE.." or "INSERT..." statements, you call the RecordSave or RecordWrite method.
You can perform queries. But the filter regexps for funny business before the command is run.
And you guys are yelling awful loud to have anything meaninful to say.
You've obviously never worked on a classified project.
I get around most of mySQL's "limitations" in TCL.
Every time you use a cliche, God kills a kitten...
Very true. It's at least 3 years ahead of the state of the art in performance and theory. Unfortunately they are also 3 years ahead of the state of the art when it comes to driver support...
Enter the joke about my brother... THE BUISNESS MAJOR.
Phone Call: Hey Sean, I just got a health club membership, can you read over the fine print?
(Two hours later, over a couple of bears)
Me: And this line item is where you are essentially financing a non-refundable $1500 "membership application" over 12 months at an ungodly interest rate.
Brother: Well I guess I stepped in it this time.
(Keep in mind, his major was business. I'm an engineering drop out.)
To make a long story short: any link is statistically insignifigant. What elevated cancer risks were found couldn't rule out other causes from chemicals, lifestyles, or location.
It turns out that lead, oil, and mercury were far more likely to have been the culprit. Each of those contaninates DID have a profound and immediate effect on the animals tested.
Links
It didn't.
File under how microwave ovens were invented. It all started with a melted candybar and a radar transmitter.
Husand: Honey I'm home!
Wife: Great, lets go out to dinner. Just make sure you take that stupid...
Husband's Pager: (BEEP BEEP BEEP)
Husband: Hang on a second honey...
(Scene shifts to a few hours later, as Husband tries to sleep on the couch.)
Cell phone signal: 4 W.
Stepping outside under full sun: 1000 W.
We are exposed to far greater amounts of EM radiation from the sun, in all sorts of unfilitered frequencies. And we have been since before man really groked that it rose every day and set every night.
I might also add that radio operators have been using very high powered equipment for more than a century. There is only one nasty effect from working around microwaves: male sterility if you are dumb enough to stand in front of a microwave tower to keep warm. And the problem there isn't the EM radiation. It's the fact that male testes don't like heat.
Today's google homework: pointillism.