George Lucas was a brilliant filmmaker on two films: Star Wars IV and American Graffiti. He had the good sense *not to direct* Episode V and VI, which is why they turned out so well in spite of how hokey Ewoks are.
I saw an interview with him around about the time of the Star Wars: A New Hope re-release. He was asked if he would ever consider reprising the role of Han Solo. He said, no. He said he didn't like the character of Han at all. When asked if he would consider playing Indiana Jones again, his immediate response was "In a second".
Ford like Jones and doesn't like Solo. It's as simple as that. He has the luxury of being able to pick his roles.
We're a 10-year-old engineering firm with about 50 employees. Out current contact database is 15,000 individual contacts.
CRM is when Outlook and Exchange alone aren't good enough. CRM software is a combination of an address book, calendar, and record keeping system. Basically, it lets you record all the information about every customer or potential customer you interact with, and it will then record every email, phone call, sale (won or lost), purchases, customer interests, etc. It then lets you manipulate all that data in your standard SQL munging, data mining ways. It can also include trouble ticket systems.
CRM is specifically targeted at sales & marketing (who primarily interact with customers). ERP/ERM software (Enterprise Resource Planning/Management) also can include vendor (purchasing) information, project management, time sheets, document libraries, customer service, financial accounting, etc.
The same argument is what gave rise to re-programmable generic processing components: CPUs. You'll note that the processor industry today (AMD in particular) is now also moving towards this kind of diversification. Gaming systems have been using dedicated GPUs for ages (today they're more powerful than entire PCs from 5 years ago) and I'm sure we remember back when math co-processors (i387) were introduced. You'll note that math co-processors were just absorbed back into the generic model.
It's another pendulum in the computing world (much like the serial/parallel dichotomy). Moving from a disparate number of diverse systems to a small number of all-purpose systems. The advances are always for performance, and they typically happen when the current generation plateaus. We've mastered the concepts of one generation, time to explore new concepts (by re-exploring old concepts).
In 10 or 15 years people will be complaining about the difficulty of data portability, the esoteric nature of these unique data files, and the lack of features in area X in one product and area Y in a second product, and the archaic languages you have to use on these old, unsupported systems. There will be a move back to generic storage engines, bringing with it the lessons learned from that round of insight.
Of course, there will always be demands for specialized components just as there will always be demand for generic, standard components. It's the centrists whose demands are for the best combination of performance and features that determine popularity.
"[D]oes not really target the consumer market, but high-end industrial applications."
Translation:
"It's damn expensive right now, and we can't produce enough of them at consumer prices to make a profit."
It goes like this. Software has bugs. These bugs can cause security vulnerabilities, which are then published and patches issued to fix the vulnerabilities. Hopefully, all this happens before the black hats can take advantage of -- or exploit -- these vulnerabilities.
An exploit of a vulnerability is the virus, worm, SQL injection, hack attempt, etc. itself. An exploit can be labelled "zero-day" when an in-the-wild exploit has been detected on the same day that the vulnerability was made known to the security industry. Most often, "zero-day" means "we learned there was a vulnerability when we found this exploit". This is rather like finding out the locks on your doors don't work when a thief has already been and gone. Zero-day exploits then will have a maximal timeframe to affect vulnerable systems since no work has been done on fixing the vulnerability (presumably).
The Slammer worm, for example, was an [i]exploit[/i] of MS SQL Server 2000. SQL Server 2000 had a buffer overflow vulerability which was the subject of Slammer. Slammer was not zero-day, however, since this security vulnerability had been known about for many months and MS had already issued patches for it (six months prior to Slammer).
The vast majority of exploits are *not* zero-day, but uninformed reporters for computer news services (like CNet, or anything Ziff Davis owns) are now using "zero-day" as a synonym for "new vulnerability" instead of the proper "new exploit to unknown vulnerability".
Nah, I'm just giving you a hard time. I've worked with a couple of people who have only ever worked on MySQL, and they tend to not know some pretty essential things for a DBA like ACID compliance and such.
It's just a function of how easy MySQL is to set up. It's trivial to set up, but a lot of the default decisions are generally bad for an SQL database, and the documentation -- while good -- never encourages you to go beyond the defaults.
It's like hearing someone say they can design websites, and then finding out they mean with FrontPage.
Drupal is one example of something that works great with MySQL. I can argue about MySQL's faults over and over, but at the end of the day it's easy to use and it's good enough for most people. CMS systems and forums are where MySQL really shines.
Clearly you've never worked in a corporate IT environment.
If your job involves writing various flavors of text files, I'm sure you have no problem at all using Linux. However, if you're in a regulated industry (like healthcare) or an industry with standard programs (like AutoCAD or Photoshop) you are locked in to Windows because it a tremendous waste of money to move away from or redevelop applications your users need to do their work.
"I can get AutoCAD or Photoshop running with WINE just fine!"
Good for you. Why should I switch? I'm already paying ludicrous amounts of licensing fees to a software vendor, and now you want me to run it on an unsupported platform? Why not just run it on Windows? If your sole motivation is political, you've got a poor argument. Windows requires no retraining since everybody knows how to use it if they have AutoCAD or Photoshop experience. Most people don't know Linux at all.
"Parallels are available!"
So? I either spend the money on software licensing, or I spend it retraining my new employees and hoping the parallels can meet the same needs that the Windows equivalent does. Why not buy what my employees already know and what they want, and save the hassle of a 6 month training period for every employee I get?
Vendor lock-in has already happened. There must be clear benefits to moving away from Windows, and "it's not Windows" is still a penalty, not a benefit. It throws away any prospective employee's computer skills, throws away however many millions of dollars have been spent in hardware and software for the current design, and generally throws away vendor support and likely means much of your IT department needs to be retrained or replaced. Considering the number of Windows IT professionals compared to Linux IT professionals, a decent sized company will quickly saturate the entire Linux market in an area.
Windows does use emulation for legacy apps. It uses the NTVDM (NT Virtual DOS Machine) for DOS apps and WoWExec (Windows-on-Windows) for 16-bit Windows apps. Their 64-bit OSs have WoW64, which emulates a 32-bit machine.
I wish he was kidding. I've seen it tried. "Dog slow" does not even begin to describe it. Typically it goes like this: App v1.0 with SQL backend; a few years later App v2.0 is released with an XML DB; a few *weeks* later App v2.5 is released changing back to SQL backend. XML is good for data serialization. It was never meant as a data storage model.
The relational model survived ODBMS proponents by forcing people to use ORMs to get any kind of production grade system. It will survive this, too, and for similar reasons.
"There is no try"? We're coding without exception handling?
I'm pretty sure I've read code written by Yoda, too. Nobody else could write backwards syntax like that which still manages to function. Jedi Master, indeed.
The way I've always heard the 2nd Amendment explained is: "Because the government plans to use militias to protect itself from foreign invaders and such, individuals should be allowed to have their own firearms to protect themselves from the government."
They are called BLOBs. In ANSI SQL, BINARY LARGE OBJECT and BLOB are datatype aliases. There are also CLOBs for CHARACTER LARGE OBJECTS, but those might be vendor-specific and not standard.
Most often I would expect to take production systems offline for an upgrade that required a schema change, which would not require ongoing data replication, yes? However, reading other posters comments here suggests that the EXECUTE SCRIPTING component of Slony is much more automated than I thought (I've never needed schema replication, and haven't needed Slony in a long while).
Slony is relatively new but it progresses very fast compared to PostgreSQL. That's one of the main reasons the project is kept as a module instead of a core component.
Binary Large OBjects (BLOBs) are table columns with individual entries are larger than several thousand bytes (typically, those that span more than one page). BLOBs are part of the ANSI SQL standard, AFAIK, which is why it is surprising you'd never heard of them. They differ from MySQL's 'blob' datatype, which is just a big TEXT field. The design of the database (PostgreSQL, DB2, Oracle, T-SQL/MS SQL, etc.) prevents such objects from being stored in the same method that other objects are stored, either because the SQL standard defines maximum sizes for fields or because the physical structure of the database makes it impractical or unreasonable. In the case of PostgreSQL, the objects are internally stored in different tables with different physical files, although that is not seen by the DB developer at all. They're typically used for storing pictures and documents in the DBMS when you cannot or do not wish to use the file system instead, or for literally storing large binary data. it also supports data streaming, AFAIK.
Table inheritance is like a reverse VIEW, and was defined in SQL:1999. Given table A and table B, let's say table B inherits from table A. Table B will then have all the fields from table A plus it's own. PostgreSQL also supports multiple inheritance. It's standard SQL, but it's very weird, IMO. It has some pretty specific uses, like being able to essentially have indexed VIEWs and such, or making a permanent JOINed table. http://www.postgresql.org/docs/8.2/interactive/ddl -inherit.html
As far as schema changes, the argument goes like this: replication is only necessary on productions systems. Schema on production systems should be static. If you're changing your schema, you probably did something wrong.
IMX, since about 7.3-7.4 PostgreSQL runs just as fast as MySQL under any significant load. It simply scales a lot better than MySQL seems to.
I will say that if you've just recently switched to PostgreSQL that you should be sure you read the documentation on configuring the server. While the default installation of MySQL is to use as much resources as necessary, PostgreSQL's default install is extremely conservative. By default it only allocated 1 MB (yes, one megabyte) for working memory. If you've got more than 32 MB of RAM, you're probably going to need to edit some config files to see any reasonable performance. Try running a VACUUM VERBOSE to determine how many pages or entries you need in your FSM. That's something that needs to be reconfigured on a production system after it's been in place for some time. If you do strange things like mass DELETEs or TRUNCATE TABLE, you'll also need to VACUUM more often.
The.org root DNS servers run on PostgreSQL, so it's not a problem with the RDBMS itself. Postgre has been repeatedly criticized for being so conservative with the default installation settings. I think they should have some configuration tools (in the Windows installer especially) that helps you to make somewhat more sane configuration settings.
The typical response from PostgreSQL devs on the subject is "yeah, if we turned off fsync on our DB it'd run real fast, too". This is partially why PostgreSQL seems to run slower than MySQL on databases that have lots of INSERT and DELETE queries.
I no longer see any reason to ever use MySQL. It's more popular, but I find PostgreSQL, Firebird, and SQLite cover the range of needs so much better. MySQL is great to learn on, but, well, it's just annoying once you really understand the first things about relational databases.
The Fed determines how much money is in circulation and places orders for paper money with the Bureau of Engraving & Printing, which is part of the Treasury Dept. (as is the US Mint which produces the nation's coins). The Treasury Department determines what the money looks like, because the Treasury Department is responsible for the security of the dollar.
The US Mint and Bureau of E&P produce money, and the Fed is their only customer.
If teachers were paid better and given more resources the job of teacher would be more sought after and a higher degree of competent teachers would be the likely result (if at the very least because higher competition would allow administrators more choices therefore weeding out those who are poor teachers). (Cultural change: 'sports stars deserve a 50 million dollar contract teachers should be happy enough just teaching my kids')
This is the problem I have seen. We expect teachers to go to college and obtain a degree that takes 5 years, student teach for a year (for free), and then start at $25,000. I made half again as much after getting a two year degree in Computer Networking. There is no incentive to become a teacher so the only people who do are those who love it and those who won't work elsewhere. Those who love it are becoming burned out. The old axiom of "those who can't... teach" is becoming true.
Slashdot Mirror
Hey, people need to have *some* reason to buy Vista. WMP 12 and IE 8 are better reasons than what they have now.
George Lucas was a brilliant filmmaker on two films: Star Wars IV and American Graffiti. He had the good sense *not to direct* Episode V and VI, which is why they turned out so well in spite of how hokey Ewoks are.
Actually, that's not it at all.
I saw an interview with him around about the time of the Star Wars: A New Hope re-release. He was asked if he would ever consider reprising the role of Han Solo. He said, no. He said he didn't like the character of Han at all. When asked if he would consider playing Indiana Jones again, his immediate response was "In a second".
Ford like Jones and doesn't like Solo. It's as simple as that. He has the luxury of being able to pick his roles.
CRM is when Outlook and Exchange alone aren't good enough. CRM software is a combination of an address book, calendar, and record keeping system. Basically, it lets you record all the information about every customer or potential customer you interact with, and it will then record every email, phone call, sale (won or lost), purchases, customer interests, etc. It then lets you manipulate all that data in your standard SQL munging, data mining ways. It can also include trouble ticket systems.
CRM is specifically targeted at sales & marketing (who primarily interact with customers). ERP/ERM software (Enterprise Resource Planning/Management) also can include vendor (purchasing) information, project management, time sheets, document libraries, customer service, financial accounting, etc.
Considering the number of FLOSS ERP and CRM products, I'm surprised more people don't know about it.
The same argument is what gave rise to re-programmable generic processing components: CPUs. You'll note that the processor industry today (AMD in particular) is now also moving towards this kind of diversification. Gaming systems have been using dedicated GPUs for ages (today they're more powerful than entire PCs from 5 years ago) and I'm sure we remember back when math co-processors (i387) were introduced. You'll note that math co-processors were just absorbed back into the generic model.
It's another pendulum in the computing world (much like the serial/parallel dichotomy). Moving from a disparate number of diverse systems to a small number of all-purpose systems. The advances are always for performance, and they typically happen when the current generation plateaus. We've mastered the concepts of one generation, time to explore new concepts (by re-exploring old concepts).
In 10 or 15 years people will be complaining about the difficulty of data portability, the esoteric nature of these unique data files, and the lack of features in area X in one product and area Y in a second product, and the archaic languages you have to use on these old, unsupported systems. There will be a move back to generic storage engines, bringing with it the lessons learned from that round of insight.
Of course, there will always be demands for specialized components just as there will always be demand for generic, standard components. It's the centrists whose demands are for the best combination of performance and features that determine popularity.
"[D]oes not really target the consumer market, but high-end industrial applications." Translation: "It's damn expensive right now, and we can't produce enough of them at consumer prices to make a profit."
"Zero-day" is an exploit classification.
It goes like this. Software has bugs. These bugs can cause security vulnerabilities, which are then published and patches issued to fix the vulnerabilities. Hopefully, all this happens before the black hats can take advantage of -- or exploit -- these vulnerabilities.
An exploit of a vulnerability is the virus, worm, SQL injection, hack attempt, etc. itself. An exploit can be labelled "zero-day" when an in-the-wild exploit has been detected on the same day that the vulnerability was made known to the security industry. Most often, "zero-day" means "we learned there was a vulnerability when we found this exploit". This is rather like finding out the locks on your doors don't work when a thief has already been and gone. Zero-day exploits then will have a maximal timeframe to affect vulnerable systems since no work has been done on fixing the vulnerability (presumably).
The Slammer worm, for example, was an [i]exploit[/i] of MS SQL Server 2000. SQL Server 2000 had a buffer overflow vulerability which was the subject of Slammer. Slammer was not zero-day, however, since this security vulnerability had been known about for many months and MS had already issued patches for it (six months prior to Slammer).
The vast majority of exploits are *not* zero-day, but uninformed reporters for computer news services (like CNet, or anything Ziff Davis owns) are now using "zero-day" as a synonym for "new vulnerability" instead of the proper "new exploit to unknown vulnerability".
Too bad they didn't warn Time Warner.
Yup. Complete with random incompatibilities and mindlessly non-standard features.
Nah, I'm just giving you a hard time. I've worked with a couple of people who have only ever worked on MySQL, and they tend to not know some pretty essential things for a DBA like ACID compliance and such.
It's just a function of how easy MySQL is to set up. It's trivial to set up, but a lot of the default decisions are generally bad for an SQL database, and the documentation -- while good -- never encourages you to go beyond the defaults.
It's like hearing someone say they can design websites, and then finding out they mean with FrontPage.
Drupal is one example of something that works great with MySQL. I can argue about MySQL's faults over and over, but at the end of the day it's easy to use and it's good enough for most people. CMS systems and forums are where MySQL really shines.
You know, I really hate to say this, but:
Spoken like a true MySQL developer.
As opposed to the US, where being on the correct side of the law means investing millions in lobby groups and election funds.
Clearly you've never worked in a corporate IT environment.
If your job involves writing various flavors of text files, I'm sure you have no problem at all using Linux. However, if you're in a regulated industry (like healthcare) or an industry with standard programs (like AutoCAD or Photoshop) you are locked in to Windows because it a tremendous waste of money to move away from or redevelop applications your users need to do their work.
"I can get AutoCAD or Photoshop running with WINE just fine!"
Good for you. Why should I switch? I'm already paying ludicrous amounts of licensing fees to a software vendor, and now you want me to run it on an unsupported platform? Why not just run it on Windows? If your sole motivation is political, you've got a poor argument. Windows requires no retraining since everybody knows how to use it if they have AutoCAD or Photoshop experience. Most people don't know Linux at all.
"Parallels are available!"
So? I either spend the money on software licensing, or I spend it retraining my new employees and hoping the parallels can meet the same needs that the Windows equivalent does. Why not buy what my employees already know and what they want, and save the hassle of a 6 month training period for every employee I get?
Vendor lock-in has already happened. There must be clear benefits to moving away from Windows, and "it's not Windows" is still a penalty, not a benefit. It throws away any prospective employee's computer skills, throws away however many millions of dollars have been spent in hardware and software for the current design, and generally throws away vendor support and likely means much of your IT department needs to be retrained or replaced. Considering the number of Windows IT professionals compared to Linux IT professionals, a decent sized company will quickly saturate the entire Linux market in an area.
Windows does use emulation for legacy apps. It uses the NTVDM (NT Virtual DOS Machine) for DOS apps and WoWExec (Windows-on-Windows) for 16-bit Windows apps. Their 64-bit OSs have WoW64, which emulates a 32-bit machine.
I wish he was kidding. I've seen it tried. "Dog slow" does not even begin to describe it. Typically it goes like this: App v1.0 with SQL backend; a few years later App v2.0 is released with an XML DB; a few *weeks* later App v2.5 is released changing back to SQL backend. XML is good for data serialization. It was never meant as a data storage model.
The relational model survived ODBMS proponents by forcing people to use ORMs to get any kind of production grade system. It will survive this, too, and for similar reasons.
"There is no try"? We're coding without exception handling?
I'm pretty sure I've read code written by Yoda, too. Nobody else could write backwards syntax like that which still manages to function. Jedi Master, indeed.
Just send them to http://www.java.com/. It's dead simple from there.
The way I've always heard the 2nd Amendment explained is: "Because the government plans to use militias to protect itself from foreign invaders and such, individuals should be allowed to have their own firearms to protect themselves from the government."
They are called BLOBs. In ANSI SQL, BINARY LARGE OBJECT and BLOB are datatype aliases. There are also CLOBs for CHARACTER LARGE OBJECTS, but those might be vendor-specific and not standard.
Most often I would expect to take production systems offline for an upgrade that required a schema change, which would not require ongoing data replication, yes? However, reading other posters comments here suggests that the EXECUTE SCRIPTING component of Slony is much more automated than I thought (I've never needed schema replication, and haven't needed Slony in a long while).
Slony is relatively new but it progresses very fast compared to PostgreSQL. That's one of the main reasons the project is kept as a module instead of a core component.
Binary Large OBjects (BLOBs) are table columns with individual entries are larger than several thousand bytes (typically, those that span more than one page). BLOBs are part of the ANSI SQL standard, AFAIK, which is why it is surprising you'd never heard of them. They differ from MySQL's 'blob' datatype, which is just a big TEXT field. The design of the database (PostgreSQL, DB2, Oracle, T-SQL/MS SQL, etc.) prevents such objects from being stored in the same method that other objects are stored, either because the SQL standard defines maximum sizes for fields or because the physical structure of the database makes it impractical or unreasonable. In the case of PostgreSQL, the objects are internally stored in different tables with different physical files, although that is not seen by the DB developer at all. They're typically used for storing pictures and documents in the DBMS when you cannot or do not wish to use the file system instead, or for literally storing large binary data. it also supports data streaming, AFAIK.
l -inherit.html
Table inheritance is like a reverse VIEW, and was defined in SQL:1999. Given table A and table B, let's say table B inherits from table A. Table B will then have all the fields from table A plus it's own. PostgreSQL also supports multiple inheritance. It's standard SQL, but it's very weird, IMO. It has some pretty specific uses, like being able to essentially have indexed VIEWs and such, or making a permanent JOINed table.
http://www.postgresql.org/docs/8.2/interactive/dd
As far as schema changes, the argument goes like this: replication is only necessary on productions systems. Schema on production systems should be static. If you're changing your schema, you probably did something wrong.
IMX, since about 7.3-7.4 PostgreSQL runs just as fast as MySQL under any significant load. It simply scales a lot better than MySQL seems to.
I will say that if you've just recently switched to PostgreSQL that you should be sure you read the documentation on configuring the server. While the default installation of MySQL is to use as much resources as necessary, PostgreSQL's default install is extremely conservative. By default it only allocated 1 MB (yes, one megabyte) for working memory. If you've got more than 32 MB of RAM, you're probably going to need to edit some config files to see any reasonable performance. Try running a VACUUM VERBOSE to determine how many pages or entries you need in your FSM. That's something that needs to be reconfigured on a production system after it's been in place for some time. If you do strange things like mass DELETEs or TRUNCATE TABLE, you'll also need to VACUUM more often.
The .org root DNS servers run on PostgreSQL, so it's not a problem with the RDBMS itself. Postgre has been repeatedly criticized for being so conservative with the default installation settings. I think they should have some configuration tools (in the Windows installer especially) that helps you to make somewhat more sane configuration settings.
The typical response from PostgreSQL devs on the subject is "yeah, if we turned off fsync on our DB it'd run real fast, too". This is partially why PostgreSQL seems to run slower than MySQL on databases that have lots of INSERT and DELETE queries.
I no longer see any reason to ever use MySQL. It's more popular, but I find PostgreSQL, Firebird, and SQLite cover the range of needs so much better. MySQL is great to learn on, but, well, it's just annoying once you really understand the first things about relational databases.
Federal guidelines also dictate things like WORM tape. Although you're obviously never going to be overwriting one of those for obvious reasons.
That's like calling a personal computer the same as a 4 function calculator. While technically correct, it completely misses the point.
The Fed determines how much money is in circulation and places orders for paper money with the Bureau of Engraving & Printing, which is part of the Treasury Dept. (as is the US Mint which produces the nation's coins). The Treasury Department determines what the money looks like, because the Treasury Department is responsible for the security of the dollar.
The US Mint and Bureau of E&P produce money, and the Fed is their only customer.
This is the problem I have seen. We expect teachers to go to college and obtain a degree that takes 5 years, student teach for a year (for free), and then start at $25,000. I made half again as much after getting a two year degree in Computer Networking. There is no incentive to become a teacher so the only people who do are those who love it and those who won't work elsewhere. Those who love it are becoming burned out. The old axiom of "those who can't... teach" is becoming true.