Close, but intellect doesn't imply a quality person. As you stated, the job they've attained isn't a measure of the quality of a person. Instead, it includes ethics, desire, spirit/attitude, direction, intention, etc, etc, etc. It takes a blend to make what we can all regard as an excellent person deserving of the ultimate respect.
Actually, I hit on a signficant realization when I was in my later years of high school. I met a bus driver who was doing an "excellent" job of driving a bus. Not a job I would aspire towards and certainly not hard, right? Except, that day I realized he was better at being a bus driver than I ever could. His attitude, driving skills, etc, etc blended to make him the ultimate bus driver and I instantly placed at or above the perceived class level of my target job.
It's happened many times since as I've met people from many lines of work and it's just as evident that you can be a respected professional in any industry. And I sure as heck hope you can appreciate someone with this kind of "class." It's not the job they're doing, it's the quality of the person standing in front of you. Good people are hard to find.
"A 150GB database is very lower mid-range for a real-world database."
I wouldn't classify that as a low- or mid-range size. If we compare against the total number of installations, I'd classify the low-end at a few hundred megabytes or less, since there are so many low-traffic sites running dynamic content or forums populating the web. I've seen MySQL installations choke with a hair over 200MB of data (not crash, but run ungodly slow), so I'm not surprised with the result. MySQL is clearly not the tool for the job here, and I don't know who recommended it based on your client requirements, but it was a mistake. In fact, I'm surprised that it even worked at all, however sluggish it was.
It's pretty obvious that their tables weren't indexed properly. Please tell me you already knew that. Poor developers are not an indication of a poor engine...
1) Every database has quirks and bugs you run into during development of large systems. Face it, not everyone is dealing with a 500GB dataset.
2) Did you pay for a MySQL.com support contract? If not, you really should have. There's a serious advantage in paid support (probably exists for postgres as well...).
3) You've heard of Wikipedia, correct? Yeah.... That's one big, heavily used, MySQL db. Last I heard, they were planning for the future and testing for multiple terabyte data sets. Seems like they're up around 500GB now. See http://meta.wikimedia.org/wiki/Wikimedia_servers for details on their server setup.
4) Your point about problems only showing up on large datasets that would be invisible with smaller datasets is dead on. I recently loaded apache logs into mysql and ran across a bug indexing TEXT columns. I finally had to index on a CRC32 of the data to get acceptable performance. As I understand, the fix should show up in the next release of 4.11, but I never would have cared with less than a a couple hundred thousand rows.
It's a bummer you ran into problems the first time through and it's also a bummer your code wasn't flexible enough to switch engines as necessary. A foray into postgres to validate problems with mysql vs problems with general approach would probably have been helpful. Oracle is free for development so that should have been investigated as well.
On your next attempt, I'd suggest you approach it by prototyping across several likely engines and see which handles your particular problem with the most grace... And try to stay away from engine specific hacks so you can move it easily in the future.
Argggg... It has subqueries (MySQL 4.1). It has transactions (INNOdb tables). It has a binary log. etc, etc, etc. Please check this kind of bull against the crash-me section of MySQL's site. http://dev.mysql.com/tech-resources/features.html
Not sure what to say about the truncation because MySQL does perform in the manner you describe. What confuses me is why you're even allowing bad data to reach the database... How about you just let your users know they entered more data than you had designed the schema to handle?
Yep, that's true... Unless wget or your text editor have a possible buffer overflow exploit or other problem. Command line apps aren't immune either...
#include disclaimer.h: IANAL. I didn't make it past second year undergrad law, and I have only the vaguest memory of torts and contract law - as reading the above ramblings demonstrates. You'd be a fool to take my advice!
Ummm, so buy the paper copy instead? The advantages of having an electronic copy are pretty compelling and the choice is never a bad thing.. I think I'll just continue to mix and match as needed.
I remember the official stance approx 2 years ago to be that if a commercial app did not *require* MySQL to run (ie, had both MySQL and Postgres support) and MySQL was not distributed with the app, then the commercial app did not need a license. The reasoning at that time was that the *customer* was choosing which database to use and so the licensing requirements fell on the end user rather than on the original developer. As such, the end user was allowed to use the GPL MySQL database just as they would if they used Apache/MySQL to run their website.
Is this still true or is policy changing?
Along the same lines, does that mean that a web development shop that creates a closed source PHP app that links against a MySQL database is now in violation? If not, why not?
Slashdot Mirror
Dunno about that.. I though WoW was blizzard's thing ;)
Just as a clarification, this is *not* a new protocol. This is a new client that integrates the AIM protocol and functionality with other services.
Yep, 'cause "Sorry, I missed the deadline because the latest Nimbda variant took over my system" sounds so much better.
In that case, pro.com is probably worth a pile of money...
Close, but intellect doesn't imply a quality person. As you stated, the job they've attained isn't a measure of the quality of a person. Instead, it includes ethics, desire, spirit/attitude, direction, intention, etc, etc, etc. It takes a blend to make what we can all regard as an excellent person deserving of the ultimate respect.
Actually, I hit on a signficant realization when I was in my later years of high school. I met a bus driver who was doing an "excellent" job of driving a bus. Not a job I would aspire towards and certainly not hard, right? Except, that day I realized he was better at being a bus driver than I ever could. His attitude, driving skills, etc, etc blended to make him the ultimate bus driver and I instantly placed at or above the perceived class level of my target job.
It's happened many times since as I've met people from many lines of work and it's just as evident that you can be a respected professional in any industry. And I sure as heck hope you can appreciate someone with this kind of "class." It's not the job they're doing, it's the quality of the person standing in front of you. Good people are hard to find.
"A 150GB database is very lower mid-range for a real-world database."
I wouldn't classify that as a low- or mid-range size. If we compare against the total number of installations, I'd classify the low-end at a few hundred megabytes or less, since there are so many low-traffic sites running dynamic content or forums populating the web. I've seen MySQL installations choke with a hair over 200MB of data (not crash, but run ungodly slow), so I'm not surprised with the result. MySQL is clearly not the tool for the job here, and I don't know who recommended it based on your client requirements, but it was a mistake. In fact, I'm surprised that it even worked at all, however sluggish it was.
It's pretty obvious that their tables weren't indexed properly. Please tell me you already knew that. Poor developers are not an indication of a poor engine...
Four things.....
1) Every database has quirks and bugs you run into during development of large systems. Face it, not everyone is dealing with a 500GB dataset.
2) Did you pay for a MySQL.com support contract? If not, you really should have. There's a serious advantage in paid support (probably exists for postgres as well...).
3) You've heard of Wikipedia, correct? Yeah.... That's one big, heavily used, MySQL db. Last I heard, they were planning for the future and testing for multiple terabyte data sets. Seems like they're up around 500GB now. See http://meta.wikimedia.org/wiki/Wikimedia_servers for details on their server setup.
4) Your point about problems only showing up on large datasets that would be invisible with smaller datasets is dead on. I recently loaded apache logs into mysql and ran across a bug indexing TEXT columns. I finally had to index on a CRC32 of the data to get acceptable performance. As I understand, the fix should show up in the next release of 4.11, but I never would have cared with less than a a couple hundred thousand rows.
It's a bummer you ran into problems the first time through and it's also a bummer your code wasn't flexible enough to switch engines as necessary. A foray into postgres to validate problems with mysql vs problems with general approach would probably have been helpful. Oracle is free for development so that should have been investigated as well.
On your next attempt, I'd suggest you approach it by prototyping across several likely engines and see which handles your particular problem with the most grace... And try to stay away from engine specific hacks so you can move it easily in the future.
Hey! That's my code! /me SCO's JamesP
Furthermore, I find that cashiers will check my face against the picture on all my cards without fail. Perhaps it's just my face?
Have I been missing something all this time?
http://dev.mysql.com/doc/mysql/en/binary-log.html
Argggg... It has subqueries (MySQL 4.1). It has transactions (INNOdb tables). It has a binary log. etc, etc, etc. Please check this kind of bull against the crash-me section of MySQL's site.
http://dev.mysql.com/tech-resources/features.html
Not sure what to say about the truncation because MySQL does perform in the manner you describe. What confuses me is why you're even allowing bad data to reach the database... How about you just let your users know they entered more data than you had designed the schema to handle?
*click*
The sound you hear as 700,000 slashdotters add you to their foes list.
Probably giving a similar error as what I get in Konqi :)
Error: node : TypeError: Undefined value
Yep, that's true... Unless wget or your text editor have a possible buffer overflow exploit or other problem. Command line apps aren't immune either...
I've even seen one that was active even when the infected drive was placed as a slave on another machine
Dude, don't click on them *again*...
Jmeter is pretty nice as well.
Konqueror 3.2.3 also displays a black box rather than crashing...
Good point. I got too deep into the 2001 ruling and forgot what the /. blurb said ;) Bummer deal that EULA style contracts were validated :(
Here's a blurb from linuxjournal on a ruling between Adobe and Softman that appears to grant Right of First Sale. Did this one get overturned?
#include disclaimer.h: IANAL. I didn't make it past second year undergrad law, and I have only the vaguest memory of torts and contract law - as reading the above ramblings demonstrates. You'd be a fool to take my advice!
;)
Which, of course, I will sue you over tomorrow
Ummm, so buy the paper copy instead? The advantages of having an electronic copy are pretty compelling and the choice is never a bad thing.. I think I'll just continue to mix and match as needed.
I just want to know how in the world someone actually had direct access to the sources :)
I remember the official stance approx 2 years ago to be that if a commercial app did not *require* MySQL to run (ie, had both MySQL and Postgres support) and MySQL was not distributed with the app, then the commercial app did not need a license. The reasoning at that time was that the *customer* was choosing which database to use and so the licensing requirements fell on the end user rather than on the original developer. As such, the end user was allowed to use the GPL MySQL database just as they would if they used Apache/MySQL to run their website.
Is this still true or is policy changing?
Along the same lines, does that mean that a web development shop that creates a closed source PHP app that links against a MySQL database is now in violation? If not, why not?
Sure, but the timing is less than wonderful and the problems created by people not wanting to sell their shares back could be ugly...