it is absolutely disingenious to hear executives say "we're shocked, shocked and appalled!" when you know DAMN WELL that accounting practices are rarely able to be hidden in the dark when they're THAT excessive... (especially when it comes to capitalization in my experience)
former employers of mine literally used to reprimand us when we didn't capitalize all our labor (which was clearly illegal in those particular cases, and everyone knew it well, but they'd actually try to defend the actions by suggesting that the accounting laws are being CHANGED in our favor in the near future).
there's never "one person" at fault for these situations, and whistleblowing is a tricky option....
either way, i enjoy seeing them (the unsavory executives) personally fail, but i hate the wake they leave in their rapid descent.
i've searched through the threads on this article, and i'm ABSOLUTELY SHOCKED that not one person has mentioned Aegis. i have used cvs since it's earliest days, and rcs prior to that (not counting a number of commercial offerings), and i must say, i despise it greatly. i find it to be EXCEEDINGLY clunky at managing concurrent development of FEATURES THAT YOU AREN'T CERTAIN ARE GOING TO MIGRATE TOGETHER INTO PRODUCTION.
see, in my experiences, when dealing with huge software systems, it's rather tough to get all DEPENDENT changes to move in lock-step with your own project's changes when the problem is rather large. given that, we end up having to create branches & associated tags for EVERY FEATURE which we then merge all around into release-branches, which all just becomes a rather kludgy mess. the time spent on source code control begins to grow exponentially, and the skill required to do this safely grows with it.
Aegis solves these problems like the commercial configuration management tools (clearcase, PCMS/PVCS, etc, etc) in that it allows for deltas to code to be aggregated together and considered as one atomic change (many times relating these together as implementing a specific managed change (say from a bug-tracking system, etc)).
this is ABSOLUTELY NECESSARY when you have hundreds of software developers on a project in my (admittedly limited in the grand scale of things) experience.
i've always been shocked that so many open source developers were simply willing to put up with cvs given all its warts.
hopefully this article and the discussions surrounding it force some folks to stand up and demand that the "state of the art" be advanced. (i realize that the state of the art is really far beyond what cvs does, but cvs HAS MIND SHARE).
btw: aegis is GPL'ed and has been around for a LONG time. in addition, it's core concepts are similar to almost every other CM tool i've used (even including cvs, not counting the advanced features) so most people can get up to speed with it quickly.
i'm also confident that the SIMPLER aspects of source code control / configuration managment could be integrated into most IDE's by building cvs-command-compliant wrappers around Aegis if the time-to-market for the integration were deemed more important than a native integration...
oh yeah, last thing: aegis heavily entices you to check in test cases for your code. i've found this to be a simple but effective mechanism to aid people in building good regression test suites...
i'm curious to see whether i'm alone in my opinions on these topics or not...
ok, just to make sure you understand, my reply was to the anonymous-coward, so you have to be browsing at the correct level to get the humour here, but i decided to include a link to the original commercial....
in some data centers i've been in, we've used UDWM multiplexors to aggregate fibre-channel runs very long distances over a single oc-192...
my reasoning for saying "scsi is dead" is really levied at SCSI-over-copper. it's just too much a hassle, and when economies of scale are in full force, it'll be more expensive, too. scsi-over-fibre = fibre-channel.
i personally think scsi-over-copper is dead, while scsi-over-fibre (fc-sw) is alive and kicking very well. switched fibre-channel is so far superior to anything "stock" scsi has to offer, it's laughable.
if you think that the only site using java applets that are of any use is http://www.afterhourstrading.com, you've clearly not been doing much except feeding your (legal) gambling habits...
there are more with superb applets than i can possibly list, but to help feed your habit, might i recommend the awesome research tools at http://www.smartmoney.com
i'm just going to play devil's advocate here, and i know this has been stated millions of times before, so don't beat me up too much for saying it, but it seems pertinent to this discussion:
are you sure you really considered the precise implications of you said when you stated "You aren't as free to do what you want with them as GNU applications"?
i'm a mostly-believer in the GPL ideals, but i don't go into it thinking that it's truly a "free" license. it seems logical to me that if it were completely and totally free (as-in-speech), there'd be no encumberances whatsoever, thus, it'd not be viral.
as it is, it's more encumbered than the BSD-style licenses, and certainly moreso than that which is released into the "public domain".
was the ability to use already-existent tools to do data mining, reporting, & other similar (not necessarily insignificant) activities...
in all cases that we had gone through rigourous prototypes of products and used ODBMS', it always seemed to come down to the same few things:
1) critical mass (everyone already knew the relational databases very well)
2) tool robustness (there are a wide variety of good tools (most 3rd party supplied) to MANAGE relational instances. i'm referring to more subtle circumstances than managing users & schema here)
3) reporting and data-mining was ALWAYS more difficult (usually by an order of magnitude or more).
now, my last involvement in a prototype is YEARS ago, so i'm absolutely positive things have changed...
the reality remains that people haven't yet gotten by what they learned in their first few experiences and simply haven't re-examined the landscape, just like myself...
a weak excuse, but i'm certain this is a more common answer than we'd all like to admit.
i searched through the patent search engines, and came across a fairly healthy intellectual property portfolio. some of those patents are describing methods that i'm almost positive are used inside oracle, for example.
this could be a tool in order to gain leverage on the competition merely from this one perspective...
as was mentioned numerous other places in the replies to this story:
the tpc-c benchmark results can be easily "enhanced" by partitioning data into multiple individual instances (unfortunately the benchmark allows this).
so, most people looking for a suitable one-box or two-machine-cluster solution are going to be confused by all these partitioned results to say the least.
if we pay attention to the non-clustered results, the IBM 680 sits at the top, while the bull, hp, & fujitsu, sun, & other offerings follow closely behind.
the important thing to note is that if you needed to buy a single box (or a pair to form a cluster or an OPS cluster if oracle) you would be making a very different decision than buying a partitioned cluster of IBM xSeries 370's. this, in fact, is the decision almost everyone looking at these types of performance numbers has to make "in the real world".
few have the luxury to partition their data into multiple instances... they usually are stuck with inescapable growing-pains from the past.
first, i am neither an employee of oracle, ibm, or sybase, nor am i a VAR, or any agent of any of the above (but am a stock holder in both ibm and oracle)... these are the three RDBMS engines i know best, i'm sure others do a bunch of these things too. the exclusion is not intentional, just ignorance.
all claims i make below generally are present across all three RDBMS', but in a few cases, they are features specific to one or the other.
to add on to what the other poster(s) has(have) already mentioned, some of the features that are as of yet unmatched by any open source RDBMS (but correct me if my information is old):
1) two-phase commit built into the kernel of the RDBMS. this is really a must-have to support a bunch of the others features to follow. don't underestimate how difficult this gets when you begin to consider MULTIPLE VERSIONS of your rdbms kernel that may need to cooperate on transactions that span over 5 or more databases (this happens all the time). i can only imagine that this is the most technically challenging software in all three kernels.
2) when you've got a problem that needs it and constraints that allow for it, symmetric replication. two distinct database instances that share the same schema objects, replicating transactions applied to either instance to it's peer, both in real time, AND disconnected (therefore, queued). the devil in details of this one is all the collision resolution rules. this is a VERY tricky tool and one must be very judicious in its use. be certain that not everything ends up looking like a nail, if you get my drift.
3) (oracle) parallel server (as already mentioned) allows for multiple "instances" on multiple machines to securely perform i/o against the same physical database on the same disks. this is a big feature that has, again, a necessity for just the right problem with just the right set of constraints...
4) SNMP trap agents that can send traps to any SNMP compliant management tool (say ITO, Tivoli, etc, etc) such that alarms can actually be aggregated into one spot for all instances in an entire enterprise. don't discount how big this could really be. the alternative is to use some type of log sniffing facility that comes with ITO, etc, and maintain filters to catch all those corner-cases (since, for example, oracle doesn't hand you those filters).
5) an extremely powerful, if not terribly devious query optimizer. this thing can be the bane of whole groups' existence (and i know people whose entire life is nothing but understanding that optimizer in and out to help hundreds or thousands of people to correctly optimize their queries), but when you understand how to make it work for you, it is INCREDIBLY powerful. most databases try hard to optimize for certain corner-cases, but generally don't do that well at it. they do well for the general case, instead. to compensate, they all allow for very specific manual query tuning that allows you to "hint" the optimizer that a particular mathematical model is going to be a closer approximation than another to your data. this is another HUGE feature that is a must-have. oracle's optimizer, for example, is able to perform joins at least 6 different ways (hashed, bitmaped, merge-sorted, nested-loop, etc. it can also make decisions based upon statistics, histograms, etc.). with so many choices, naturally the optimizer can't always spend enough time to choose right on every query (as it must spend predictable-time in the query-plan calculation, and i regularly see 10 page SQL queries. yuck.).
6) materialized views - the ability to store an entire query's result set as an "appendix" to a table such that when the optimizer sees a repeated query with the same where clause, it simply short-circuits the query to read the already-calculated result set. remember the oracle contest a few years back? this was their evil trick on how they could ensure no one could beat them at their own game. AN INCREDIBLY useful tool for most situations in data warehousing.
7) table partitioning. one can build a "partitioned" table by some partitioning key. the rdbms' optimizer then can selectivly discard entire partitions from a query's access plan on the fly if the first column in the index it intends to use matches the partitioning key (but this isn't the important part). key, however, is that you can partition data (say by date) and drop whole partitions of the table without having to have some very serious queries running against the table that delete a half billion rows (which, of course, cause other running queries to have to deal with the data saved in rollback for all those rows, usually causing "snapshot too old" (in oracle) errors. this has to do with transaction isolation level and the limits to what you can do if you delete billions of rows). instead, you just drop the whole partition that contained those rows out of the table, and along with it go all the index blocks from any global indexes that span partitions.
8) callbacks outside the database. you can configure oracle (not sure of the others) to make calls to EXTERNAL PROCESSES to the database kernel in order to handle certain things types of things or data. this can be immensely powerful when you need to do notifications via a trigger regarding cache-invalidation, for example.
9) i can think of some first-hand examples where 10k two-tier clients are connected to RDBMS' performing hundreds of millions (if not billions with all the automated processes) of transactions per day.
10) online backup and recovery (where applicable). again, this isn't as easy as it might sound and is a huge deal. some vendors now support both full and incremental (through custom software) backups of their databases. this is easy to dream about, but very difficult to make happen. it's, as everything else, a matter of TIME to get it perfected.
that said, of course, none of this software is perfectly implemented, and without the vendor's support organization, you'd be floating the niagra river in a wicker-basket.
all of these packages are really HUGE pieces of software that really stretch the limits of what these companies can manage with THOUSANDS of people working on them. literally. there isn't a day that goes by that we don't stumble onto some other bug in one of the three.
it's getting so complex that i personally can't imagine how any could ever be made to be bug free, as the product development folks never let the kernel of the rdbms' sit still for too long...
it's a problem of eternal scope-creep...
just my 0.02...
hope this helps a bit. there are hundreds more subtle things like this... this is why people say "enterprise features!" it's really quite difficult to explain until you actually need the features yourself.:)
you can infer some of the other features by examining the release notes of various oracle, db2, sybase, (& to a lesser degree sql2k) releases...
regarding sequences: i totally agree.
this is significantly more valueable with one caveat:
if you have multiple databases replicated in different spots (say different customer service centers in different geographic locations) you are usually forced to do manual partitioning with the sequences to keep your data segmented (and thus not colliding).
it's a corner-case, i conced, but could theoretically be easier with some type of transactionally-aware auto-increment implemented inside the rdbms' transaction layer instead. (sequences are NON TRANSACTIONAL, remember)
i don't agree with your statement that foreign keys are really only applicable to schema that is expected to see NO deletions performed against it.
i can envision many cases where i want to ensure that a parent table's row exists before i go decorating that parent with additional rows in a child table (say in a star schema).
i have actually built a few simple applications that did add additional attributes to some base object by decorating it inside a child table in this manner. most were normalized to third-normal and backed off from just a bit.
this just makes relatively good sense if you expect people to be using the schema OUTSIDE some very well controlled and implemented abstraction layer. if the abstraction layer (say some object-relational mapping) is the only inserter/updater of the tables, and you just use the relational engine to do REPORTING efficiently, then heck, no foreign keys necessary at all:)
so, foreign keys are still pretty useful for even insert-then-select schema objects, but it depends upon the situation, as usual...
i had a posting somewhere above, but i believe this is a purchase for INTELLECTUAL PROPERTY RIGHTS. there are a number of key patents that informix has been granted (it looks like searching the patent database that about 17 fairly good patents have been granted since 1996 to them). one of these is, for example, describes the method by which you could implementing a two-phase-commit transaction processing monitor inside the kernel of the RDBMS itself (which oracle has also done, for instance).
i think this was a leverage purchase, no more no less, but what do i know.
if you've really been following the RDBMS market for about 10 years, informix has really been in a very precarious position for the last 7 of them, or so. they've done rather poorly financially, and the (ISV) software development community has only barely continued to support them from what i've seen.
there's absolutely no surprise in any of this to me...
ibm is buying *INTELLECTUAL PROPERTY*, first and foremost.
searching patent databases shows us that since 1996 somewhere around 17 very useful (and non-frivilous) patents have been granted to informix. i'm fairly certain that a number of these methods are directly used by oracle in their engine (say the one that discusses the method of building a two-phase commit engine into the RDBMS itself).
in short, ibm (beelzebub) has now a new lever to exert force onto larry (satan himself)...
clearly, swordsmanship has one and only one purpose, to kill a living thing...
see, the problem with your argument is that humans evolve and refactor their behaviours over time.
what was once an act of survival (say weaponry for survival of the race, tribe, etc), becomes a sought after skill, those who excel in it are revered, after which it occationally morphs into a "sport". not everyone can be good at it, thus it becomes a means for competition.
so, i buy your argument if things are always static and human ideals don't change. unfortunately, i happen to believe it's not actually that simple:)
so go to jboss.org and examine their *already bundled* aggregate of jboss+tomcat or jboss+jetty...
it's quite stable, extremely well engineered, and may just be my favorite container... (still a few things that i'm not entirely sold on, but the rationale is starting to sink in)
correct me if i'm wrong, but was the original poster of the ipf/ipnat thread talking about JUST THE TOOLS?
i presumed they were referring to the entire packet filtering architecture in the *bsd kernels, not the tools themselves. am i totally off in the weeds here?
regarding the lisa, it was "First proposed in late 1978 by Steve Jobs..."
then, later, the discussion goes "When we started the Lisa project in late 1978..."
next, "The first Lisa application was a Forms Editor...(Figure 2 - 7/79)" (i'm going to assume that means july, 1979).
so, it seems here that we can infer that the interface design occurred between late 1978, and mid 1979. everything up to late 1978 was just concept inside apple per this documentation.
so, later we see "While consistent with the appearance of business equipment of 1979, the first Lisa interface was not very exciting to use" suggesting that they hadn't yet been satisfied that this was a sellable product. thus, it was still an R&D exercise.
good enough, makes sense.
now notice:
"The visit to Xerox was prompted after a number of people read papers published by Xerox about their Smalltalk environment [Goldberg 1978]."
interestingly enough, i can't find reference to anything published by adele goldberg while at PARC during 1978, but let's assume it is real.
if this is the case, that means that the majority of the thought that went into this paper occurred at WORST during the first half of 1978, or maybe the latter half of 1977 (they probably were NOT in any big rush to publish something here.. it was still pretty much an unknown how this would impact the world). this still places things at a half year, or so, out front apple. in reality, i think the collected thought behind the implementation of UI components in smalltalk actually predate 1977 by a few years per the documentation i'm finding at PARC on the topic.
now, all this would be fine & good, until you look at the history of "Star".
"When Star was first introduced in 1981, its bitmapped screen, windows, mouse-driven interface, and icons were unique in the marketplace...", and it should be noted that this was a SHIPPING PRODUCT.
seems to me that assuming that paper was published by goldberg when it was, and that the history of "Star" is as published in the linked document, the PARC researchers still deserve the vast majority of the credit for advancing the state of the art, while apple deserves the credit for popularizing it...
seems pretty cut and dry to me...
am i missing something?
is this history as documented inaccurate?
even more astounding is that they didn't file for this particular patent suite until may of 1999 (one of the dependents was first).
if i remember correctly, even OPEN SOURCE window managers were already using the (maybe even identical) methodology described in their claims by that time...
(so, yes, we agree it's an obvious method, but i do believe that this was in total common use by their file-date)
heck, the first beta version of litestep (the openstep-like replacement window manager/theme for windows 95, 98 & nt) went out to folks on:
December 14, 1997 (http://www.litestep.com/page-about.shtml)
a bad example, but one that totally readily popped into my head that i knew had a history on their about page...
acutally, this isn't quite true per my last understanding...
unless i've missed a great deal of information, the motorola cybersurfers that time warner hands out have domaining that disallows you (without some type of administrative control over the cable modem) to receive frames destined for any other serial number of modem. basically their encapsulation is loosely encrypted (i doubt it's actually secure).
the reason i mention this is that you said "anyone" which i don't believe is accurate... someone SKILLED, yes, ANYONE, no.:)
i.e. their promiscuous mode doesn't appear to be able to be enabled without some "inside knowledge".
is my information aged?
(i only see broadcasts to *ALL* MAC addresses (i.e. destination MAC of FF:FF:FF:FF:FF:FF, and to my specific MAC address of my firewall's external ethernet interface)
in this case, i don't think it'd be unreasonable for megacorp to demand an escrow of the source code to garage-shop's leased application either. (forget keys, they're usually temporal)
it is the perfect solution that almost any reasonable software company would be willing to accept.
i know some pretty large companies that did this very thing while they were still wee little 5-person shops:)
Slashdot Mirror
to add to this:
it is absolutely disingenious to hear executives say "we're shocked, shocked and appalled!" when you know DAMN WELL that accounting practices are rarely able to be hidden in the dark when they're THAT excessive... (especially when it comes to capitalization in my experience)
former employers of mine literally used to reprimand us when we didn't capitalize all our labor (which was clearly illegal in those particular cases, and everyone knew it well, but they'd actually try to defend the actions by suggesting that the accounting laws are being CHANGED in our favor in the near future).
there's never "one person" at fault for these situations, and whistleblowing is a tricky option....
either way, i enjoy seeing them (the unsavory executives) personally fail, but i hate the wake they leave in their rapid descent.
cheers.
Peter
i've searched through the threads on this article, and i'm ABSOLUTELY SHOCKED that not one person has mentioned Aegis. i have used cvs since it's earliest days, and rcs prior to that (not counting a number of commercial offerings), and i must say, i despise it greatly. i find it to be EXCEEDINGLY clunky at managing concurrent development of FEATURES THAT YOU AREN'T CERTAIN ARE GOING TO MIGRATE TOGETHER INTO PRODUCTION.
see, in my experiences, when dealing with huge software systems, it's rather tough to get all DEPENDENT changes to move in lock-step with your own project's changes when the problem is rather large. given that, we end up having to create branches & associated tags for EVERY FEATURE which we then merge all around into release-branches, which all just becomes a rather kludgy mess. the time spent on source code control begins to grow exponentially, and the skill required to do this safely grows with it.
Aegis solves these problems like the commercial configuration management tools (clearcase, PCMS/PVCS, etc, etc) in that it allows for deltas to code to be aggregated together and considered as one atomic change (many times relating these together as implementing a specific managed change (say from a bug-tracking system, etc)).
this is ABSOLUTELY NECESSARY when you have hundreds of software developers on a project in my (admittedly limited in the grand scale of things) experience.
i've always been shocked that so many open source developers were simply willing to put up with cvs given all its warts.
hopefully this article and the discussions surrounding it force some folks to stand up and demand that the "state of the art" be advanced. (i realize that the state of the art is really far beyond what cvs does, but cvs HAS MIND SHARE).
btw: aegis is GPL'ed and has been around for a LONG time. in addition, it's core concepts are similar to almost every other CM tool i've used (even including cvs, not counting the advanced features) so most people can get up to speed with it quickly.
i'm also confident that the SIMPLER aspects of source code control / configuration managment could be integrated into most IDE's by building cvs-command-compliant wrappers around Aegis if the time-to-market for the integration were deemed more important than a native integration...
oh yeah, last thing: aegis heavily entices you to check in test cases for your code. i've found this to be a simple but effective mechanism to aid people in building good regression test suites...
i'm curious to see whether i'm alone in my opinions on these topics or not...
cheers
Peter
ok, just to make sure you understand, my reply was to the anonymous-coward, so you have to be browsing at the correct level to get the humour here, but i decided to include a link to the original commercial....
it's available here.
heheheh
we at work almost all busted a gut reading your reply...
HILARIOUS!
that commercial was awesome!
Peter
hi...
in some data centers i've been in, we've used UDWM multiplexors to aggregate fibre-channel runs very long distances over a single oc-192...
my reasoning for saying "scsi is dead" is really levied at SCSI-over-copper. it's just too much a hassle, and when economies of scale are in full force, it'll be more expensive, too. scsi-over-fibre = fibre-channel.
i personally think scsi-over-copper is dead, while scsi-over-fibre (fc-sw) is alive and kicking very well. switched fibre-channel is so far superior to anything "stock" scsi has to offer, it's laughable.
cheers.
peter
if you think that the only site using java applets that are of any use is http://www.afterhourstrading.com, you've clearly not been doing much except feeding your (legal) gambling habits...
there are more with superb applets than i can possibly list, but to help feed your habit, might i recommend the awesome research tools at http://www.smartmoney.com
just my 0.02
peter
i'm just going to play devil's advocate here, and i know this has been stated millions of times before, so don't beat me up too much for saying it, but it seems pertinent to this discussion:
are you sure you really considered the precise implications of you said when you stated "You aren't as free to do what you want with them as GNU applications"?
i'm a mostly-believer in the GPL ideals, but i don't go into it thinking that it's truly a "free" license. it seems logical to me that if it were completely and totally free (as-in-speech), there'd be no encumberances whatsoever, thus, it'd not be viral.
as it is, it's more encumbered than the BSD-style licenses, and certainly moreso than that which is released into the "public domain".
just my 0.02.
Peter
was the ability to use already-existent tools to do data mining, reporting, & other similar (not necessarily insignificant) activities...
in all cases that we had gone through rigourous prototypes of products and used ODBMS', it always seemed to come down to the same few things:
1) critical mass (everyone already knew the relational databases very well)
2) tool robustness (there are a wide variety of good tools (most 3rd party supplied) to MANAGE relational instances. i'm referring to more subtle circumstances than managing users & schema here)
3) reporting and data-mining was ALWAYS more difficult (usually by an order of magnitude or more).
now, my last involvement in a prototype is YEARS ago, so i'm absolutely positive things have changed...
the reality remains that people haven't yet gotten by what they learned in their first few experiences and simply haven't re-examined the landscape, just like myself...
a weak excuse, but i'm certain this is a more common answer than we'd all like to admit.
just my 0.02.
Peter
on-board venture capitalists!
now THERE's a hot seller!
:)
Peter
my opinion, and only that:
i searched through the patent search engines, and came across a fairly healthy intellectual property portfolio. some of those patents are describing methods that i'm almost positive are used inside oracle, for example.
this could be a tool in order to gain leverage on the competition merely from this one perspective...
time will tell...
Peter
i'll add to this.
as was mentioned numerous other places in the replies to this story:
the tpc-c benchmark results can be easily "enhanced" by partitioning data into multiple individual instances (unfortunately the benchmark allows this).
so, most people looking for a suitable one-box or two-machine-cluster solution are going to be confused by all these partitioned results to say the least.
if we pay attention to the non-clustered results, the IBM 680 sits at the top, while the bull, hp, & fujitsu, sun, & other offerings follow closely behind.
the important thing to note is that if you needed to buy a single box (or a pair to form a cluster or an OPS cluster if oracle) you would be making a very different decision than buying a partitioned cluster of IBM xSeries 370's. this, in fact, is the decision almost everyone looking at these types of performance numbers has to make "in the real world".
few have the luxury to partition their data into multiple instances... they usually are stuck with inescapable growing-pains from the past.
cheers.
Peter
damn!
ran out of mod points.
you're not kidding, though.
this might be the best post i've seen in a while.
makes you wonder what the last two dozen years of research into transaction processing & relational database management were wasted on?
cheers.
Peter
first, i am neither an employee of oracle, ibm, or sybase, nor am i a VAR, or any agent of any of the above (but am a stock holder in both ibm and oracle)... these are the three RDBMS engines i know best, i'm sure others do a bunch of these things too. the exclusion is not intentional, just ignorance.
:)
all claims i make below generally are present across all three RDBMS', but in a few cases, they are features specific to one or the other.
to add on to what the other poster(s) has(have) already mentioned, some of the features that are as of yet unmatched by any open source RDBMS (but correct me if my information is old):
1) two-phase commit built into the kernel of the RDBMS. this is really a must-have to support a bunch of the others features to follow. don't underestimate how difficult this gets when you begin to consider MULTIPLE VERSIONS of your rdbms kernel that may need to cooperate on transactions that span over 5 or more databases (this happens all the time). i can only imagine that this is the most technically challenging software in all three kernels.
2) when you've got a problem that needs it and constraints that allow for it, symmetric replication. two distinct database instances that share the same schema objects, replicating transactions applied to either instance to it's peer, both in real time, AND disconnected (therefore, queued). the devil in details of this one is all the collision resolution rules. this is a VERY tricky tool and one must be very judicious in its use. be certain that not everything ends up looking like a nail, if you get my drift.
3) (oracle) parallel server (as already mentioned) allows for multiple "instances" on multiple machines to securely perform i/o against the same physical database on the same disks. this is a big feature that has, again, a necessity for just the right problem with just the right set of constraints...
4) SNMP trap agents that can send traps to any SNMP compliant management tool (say ITO, Tivoli, etc, etc) such that alarms can actually be aggregated into one spot for all instances in an entire enterprise. don't discount how big this could really be. the alternative is to use some type of log sniffing facility that comes with ITO, etc, and maintain filters to catch all those corner-cases (since, for example, oracle doesn't hand you those filters).
5) an extremely powerful, if not terribly devious query optimizer. this thing can be the bane of whole groups' existence (and i know people whose entire life is nothing but understanding that optimizer in and out to help hundreds or thousands of people to correctly optimize their queries), but when you understand how to make it work for you, it is INCREDIBLY powerful. most databases try hard to optimize for certain corner-cases, but generally don't do that well at it. they do well for the general case, instead. to compensate, they all allow for very specific manual query tuning that allows you to "hint" the optimizer that a particular mathematical model is going to be a closer approximation than another to your data. this is another HUGE feature that is a must-have. oracle's optimizer, for example, is able to perform joins at least 6 different ways (hashed, bitmaped, merge-sorted, nested-loop, etc. it can also make decisions based upon statistics, histograms, etc.). with so many choices, naturally the optimizer can't always spend enough time to choose right on every query (as it must spend predictable-time in the query-plan calculation, and i regularly see 10 page SQL queries. yuck.).
6) materialized views - the ability to store an entire query's result set as an "appendix" to a table such that when the optimizer sees a repeated query with the same where clause, it simply short-circuits the query to read the already-calculated result set. remember the oracle contest a few years back? this was their evil trick on how they could ensure no one could beat them at their own game. AN INCREDIBLY useful tool for most situations in data warehousing.
7) table partitioning. one can build a "partitioned" table by some partitioning key. the rdbms' optimizer then can selectivly discard entire partitions from a query's access plan on the fly if the first column in the index it intends to use matches the partitioning key (but this isn't the important part). key, however, is that you can partition data (say by date) and drop whole partitions of the table without having to have some very serious queries running against the table that delete a half billion rows (which, of course, cause other running queries to have to deal with the data saved in rollback for all those rows, usually causing "snapshot too old" (in oracle) errors. this has to do with transaction isolation level and the limits to what you can do if you delete billions of rows). instead, you just drop the whole partition that contained those rows out of the table, and along with it go all the index blocks from any global indexes that span partitions.
8) callbacks outside the database. you can configure oracle (not sure of the others) to make calls to EXTERNAL PROCESSES to the database kernel in order to handle certain things types of things or data. this can be immensely powerful when you need to do notifications via a trigger regarding cache-invalidation, for example.
9) i can think of some first-hand examples where 10k two-tier clients are connected to RDBMS' performing hundreds of millions (if not billions with all the automated processes) of transactions per day.
10) online backup and recovery (where applicable). again, this isn't as easy as it might sound and is a huge deal. some vendors now support both full and incremental (through custom software) backups of their databases. this is easy to dream about, but very difficult to make happen. it's, as everything else, a matter of TIME to get it perfected.
that said, of course, none of this software is perfectly implemented, and without the vendor's support organization, you'd be floating the niagra river in a wicker-basket.
all of these packages are really HUGE pieces of software that really stretch the limits of what these companies can manage with THOUSANDS of people working on them. literally. there isn't a day that goes by that we don't stumble onto some other bug in one of the three.
it's getting so complex that i personally can't imagine how any could ever be made to be bug free, as the product development folks never let the kernel of the rdbms' sit still for too long...
it's a problem of eternal scope-creep...
just my 0.02...
hope this helps a bit. there are hundreds more subtle things like this... this is why people say "enterprise features!" it's really quite difficult to explain until you actually need the features yourself.
you can infer some of the other features by examining the release notes of various oracle, db2, sybase, (& to a lesser degree sql2k) releases...
cheers.
Peter
regarding sequences: i totally agree.
this is significantly more valueable with one caveat:
if you have multiple databases replicated in different spots (say different customer service centers in different geographic locations) you are usually forced to do manual partitioning with the sequences to keep your data segmented (and thus not colliding).
it's a corner-case, i conced, but could theoretically be easier with some type of transactionally-aware auto-increment implemented inside the rdbms' transaction layer instead. (sequences are NON TRANSACTIONAL, remember)
cheers.
Peter
i don't agree with your statement that foreign keys are really only applicable to schema that is expected to see NO deletions performed against it.
:)
i can envision many cases where i want to ensure that a parent table's row exists before i go decorating that parent with additional rows in a child table (say in a star schema).
i have actually built a few simple applications that did add additional attributes to some base object by decorating it inside a child table in this manner. most were normalized to third-normal and backed off from just a bit.
this just makes relatively good sense if you expect people to be using the schema OUTSIDE some very well controlled and implemented abstraction layer. if the abstraction layer (say some object-relational mapping) is the only inserter/updater of the tables, and you just use the relational engine to do REPORTING efficiently, then heck, no foreign keys necessary at all
so, foreign keys are still pretty useful for even insert-then-select schema objects, but it depends upon the situation, as usual...
just my 0.02.
Peter
i had a posting somewhere above, but i believe this is a purchase for INTELLECTUAL PROPERTY RIGHTS. there are a number of key patents that informix has been granted (it looks like searching the patent database that about 17 fairly good patents have been granted since 1996 to them). one of these is, for example, describes the method by which you could implementing a two-phase-commit transaction processing monitor inside the kernel of the RDBMS itself (which oracle has also done, for instance).
i think this was a leverage purchase, no more no less, but what do i know.
cheers.
Peter
if you've really been following the RDBMS market for about 10 years, informix has really been in a very precarious position for the last 7 of them, or so. they've done rather poorly financially, and the (ISV) software development community has only barely continued to support them from what i've seen.
there's absolutely no surprise in any of this to me...
ibm is buying *INTELLECTUAL PROPERTY*, first and foremost.
searching patent databases shows us that since 1996 somewhere around 17 very useful (and non-frivilous) patents have been granted to informix. i'm fairly certain that a number of these methods are directly used by oracle in their engine (say the one that discusses the method of building a two-phase commit engine into the RDBMS itself).
in short, ibm (beelzebub) has now a new lever to exert force onto larry (satan himself)...
cheers.
Peter
ok, by this argument, fencing should be outlawed.
:)
clearly, swordsmanship has one and only one purpose, to kill a living thing...
see, the problem with your argument is that humans evolve and refactor their behaviours over time.
what was once an act of survival (say weaponry for survival of the race, tribe, etc), becomes a sought after skill, those who excel in it are revered, after which it occationally morphs into a "sport". not everyone can be good at it, thus it becomes a means for competition.
so, i buy your argument if things are always static and human ideals don't change. unfortunately, i happen to believe it's not actually that simple
cheers.
Peter
so go to jboss.org and examine their *already bundled* aggregate of jboss+tomcat or jboss+jetty...
it's quite stable, extremely well engineered, and may just be my favorite container... (still a few things that i'm not entirely sold on, but the rationale is starting to sink in)
cheers.
Peter
correct me if i'm wrong, but was the original poster of the ipf/ipnat thread talking about JUST THE TOOLS?
i presumed they were referring to the entire packet filtering architecture in the *bsd kernels, not the tools themselves. am i totally off in the weeds here?
Peter
help steer me right here.
:)
in the article you linked, and i'll try to quote:
regarding the lisa, it was "First proposed in late 1978 by Steve Jobs..."
then, later, the discussion goes "When we started the Lisa project in late 1978..."
next, "The first Lisa application was a Forms Editor...(Figure 2 - 7/79)" (i'm going to assume that means july, 1979).
so, it seems here that we can infer that the interface design occurred between late 1978, and mid 1979. everything up to late 1978 was just concept inside apple per this documentation.
so, later we see "While consistent with the appearance of business equipment of 1979, the first Lisa interface was not very exciting to use" suggesting that they hadn't yet been satisfied that this was a sellable product. thus, it was still an R&D exercise.
good enough, makes sense.
now notice:
"The visit to Xerox was prompted after a number of people read papers published by Xerox about their Smalltalk environment [Goldberg 1978]."
interestingly enough, i can't find reference to anything published by adele goldberg while at PARC during 1978, but let's assume it is real.
if this is the case, that means that the majority of the thought that went into this paper occurred at WORST during the first half of 1978, or maybe the latter half of 1977 (they probably were NOT in any big rush to publish something here.. it was still pretty much an unknown how this would impact the world). this still places things at a half year, or so, out front apple. in reality, i think the collected thought behind the implementation of UI components in smalltalk actually predate 1977 by a few years per the documentation i'm finding at PARC on the topic.
now, all this would be fine & good, until you look at the history of "Star".
check here for that history.
one little snippet:
"When Star was first introduced in 1981, its bitmapped screen, windows, mouse-driven interface, and icons were unique in the marketplace...", and it should be noted that this was a SHIPPING PRODUCT.
seems to me that assuming that paper was published by goldberg when it was, and that the history of "Star" is as published in the linked document, the PARC researchers still deserve the vast majority of the credit for advancing the state of the art, while apple deserves the credit for popularizing it...
seems pretty cut and dry to me...
am i missing something?
is this history as documented inaccurate?
just curious
cheers.
Peter
agreed.
even more astounding is that they didn't file for this particular patent suite until may of 1999 (one of the dependents was first).
if i remember correctly, even OPEN SOURCE window managers were already using the (maybe even identical) methodology described in their claims by that time...
(so, yes, we agree it's an obvious method, but i do believe that this was in total common use by their file-date)
heck, the first beta version of litestep (the openstep-like replacement window manager/theme for windows 95, 98 & nt) went out to folks on:
December 14, 1997 (http://www.litestep.com/page-about.shtml)
a bad example, but one that totally readily popped into my head that i knew had a history on their about page...
just my 0.02
Peter
acutally, this isn't quite true per my last understanding...
:)
unless i've missed a great deal of information, the motorola cybersurfers that time warner hands out have domaining that disallows you (without some type of administrative control over the cable modem) to receive frames destined for any other serial number of modem. basically their encapsulation is loosely encrypted (i doubt it's actually secure).
the reason i mention this is that you said "anyone" which i don't believe is accurate... someone SKILLED, yes, ANYONE, no.
i.e. their promiscuous mode doesn't appear to be able to be enabled without some "inside knowledge".
is my information aged?
(i only see broadcasts to *ALL* MAC addresses (i.e. destination MAC of FF:FF:FF:FF:FF:FF, and to my specific MAC address of my firewall's external ethernet interface)
cheers.
Peter
agreed.
:)
in this case, i don't think it'd be unreasonable for megacorp to demand an escrow of the source code to garage-shop's leased application either. (forget keys, they're usually temporal)
it is the perfect solution that almost any reasonable software company would be willing to accept.
i know some pretty large companies that did this very thing while they were still wee little 5-person shops
cheers.
Peter
uh....
huh?