"The main contender, ReiserFS, dropped out of the race because its creator decided to pursue other interests, but other than that everything is the same."
my favorite is "...mathematics has no expiration date". it echoes quite well with pg's assertion (on why lisp is not obsolete, in revenge of nerds) "...it was not technology but math, and math doesn't get stale"
The rub in this case is that Franz's licensing terms (involving royalties on the products you create using their product) are even more heinous than typical proprietary software.
I can't find it at the moment, but I remember reading somewhere that Franz's support team goes way above and beyond what other vendors are willing to do. Supposedly, their developers work very closely with you, if necessary, in order to get the most out of the product. To the point of helping you write code in your own app. It's not so bad having a team of experts at your disposal when you're trying to scale your startup app that suddenly became popular overnight. I think the licensing terms are negotiated on a case by case basis too so the royalties thing may not be set in stone.
It's certainly understandable why people would be turned off by their license, but it's not necessarily a bad deal. It also says a lot that Franz has been in business as long as they have with this type of license. The customers who have signed on must be getting something worthwhile out of it.
It has been quite a long time since I last looked into Franz' licensing terms, but I believe the royalty applies only if you distribute a product which contains the Allegro CL runtime. In other words, if you write a Lisp application, using Allegro CL, and you deliver it to a customer, then the customer effectively has a copy of Allegro CL. Franz wants to be compensated for this. If you wrote a server-side product, then Allegro CL is expensive, yes, but you just pay for the number of licenses you need. No royalties, as far as I know.
This is totally off topic... Is it really necessary to mod someone down to -8? Sure, the comment deserved to be modded down, but isn't -1 or -2 enough? At that point the font changes to light gray and you can barely see it anyway. It seems like modding it down after that is just beating a dead horse. I could understand if it was offensive, but this is a typical stupid comment that doesn't contribute to the discussion.
their software is ridiculously fast. one problem (in the 2.x series), is that there were NO CONCURRENT READS from the database. all access was serialized.
it looks like they may have addressed that in 3.x by allowing read-only copies, but still, c'mon!
if your workload is one that can deal with those limitations, its an awesome product. but it definitely restricts the areas-of-use.
"In the example above (likes julie ?x), x refers to everyone in the database defined in the second place of the binary relation likes. Note that the variable x must mean the same person in (likes julie ?x) and (likes ?x ?y). Similarly, the variable y must mean the same thing in (likes ?x ?y) and (girl ?y). Intuitively, the clause above says that Julie likes some person x if there is some person y that x likes who is a girl. Or, as we said originally, Julie likes anyone who likes girls. Can you represent this information in a traditional database?"
Yes/no depending on your perspective. "anyone who likes girls" is a variable so you have to convert it to a domain: "everyone who likes girls."
Is there a difference? Using a domain seems more useful to me, but maybe my brain has been corrupted by too much database work.
You can convert this to a domain, but I'm still not sure how to say Julie likes everyone who likes girls. Using dependent data definitions in SQL gets very tricky very quickly. You can do it in a view, but a view is not designed to represent information, merely to present it.
Assuming you could easily state that "Julie likes everyone who likes girls" once you converted the variable to a domain, you're still forced into a very rigid structure. If you're in a situation where a piece of knowledge in the database is unique for a given row, you wouldn't be able to convert everything to domains. Consider a situation where you're representing information about patients' blood tests. There are some basic tests that you can pigeonhole in a domain, but what about very specialized tests that only a handful of patients ever take?
I think this is definitely a case of Blub for both of us. If we were to be set free from the relational way of thinking, we'd be solving problems we can't even think up now.
Same with "Bob's age is not 30". Age is a variable so you have to covert it to a domain. In order to do that you have to explicitly say what "not 30" means. I'd say it means 1 - 29, 31 - 120. But look what happened. The original, variable, version depended on implicit information in people's brains regarding the possible range of human ages. The domain version makes this information explicit.
This is exactly what rules/sucks about relational databases. Everything is harder because you can't get away with statements that are subjectively ambiguous.
Nice...