On modern processors, the performance of a program is affected greatly by the success of the branch-prediction system, which gets hints from the compiler.
There's an interesting claim I have seen made: Apparently the late binding feature of object-oriented languages -- virtual methods in C++, any non-static method in Java -- works against branch prediction, effectively resetting the prediction state whenever such a call is made, because the target jump address must be resolved -- read from a memory location -- only at the time of the jump. If this claim is accurate, this means typical OO code is inherently slower to execute than non-OO code on modern processors. Of course, the problem will equally apply to any language that supports function pointers, and in particular to C programs "emulating" OO with structs and function-pointer tables.
I consider allowing this behavior to be rather untypeful:...
In your example, you're not "changing the type of a", you're assigning a different value to the symbol a. In Python and other strongly-dynamically typed languages such as Ruby and Lisp, values, not symbols, have types.
Python is strongly typed -- it provides a powerful typing system and enforces typing rules -- and it's also dynamically typed, meaning that any symbol can assume any value, so type errors cannot be detected at runtime. A statically typed language, as the name implies, requires that symbols be declared as a specific type, and type rules will be enforced on syntax at compile time (statically-typed languages such as C++ and Java require additional runtime type checking due to their support for late binding support, ie. polymorphism).
There is at least one proposal for an optional, static type system for Python (something like symbol: type like Pascal). There is also a proposal, by the Zope Corp. people, for adding interfaces to the language.
That said, there are other irritating things about the way projects are managed... like having just one huge, flat list of projects, and not having the option to hide closed projects.
There's a filter to hide closed projects. Package Explorer > Filters > Closed projects.
Eclipse doesn't yet support true nested projects, and directories must not overlap. You can probably mess around with exclusions and make it work somehow, but I probably wouldn't do it personally. Splitting the project into two orthogonal directories sounds like a small sacrifice to make, though.
A more appropriate candidate for nested projects, imho, is API/implementation/test separation, and other subset/layer dependency issues.
For example, let's say your framework project has an interface package and an implementation package. The two packages should be compiled into two different JARs. Client applications should only depend on the interface package, through the interface JAR. Similarly, nobody probably needs the test package, so shouldn't need to link to it, but the test package needs the intf and impl packages, and should be compiled into its own JAR. If you have an internal plug-in system, you might want a fourth package for those interfaces/classes.
With Eclipse you still can't do this, and you would have to divide the project into different projects, in this case intf, impl and test. You could do it easily with nested projects, however.
Re:I'd like to weigh in ...
on
Eclipse in Action
·
· Score: 2, Informative
HomeSite creates a project file (projectname.apf) in the top folder of the project. It contains a complete list of all the files in the project, and can organize it either by physical folders
This is analogous to how Eclipse does things. Each project is a separate entity. A project can link to different parts of the file system ("virtual" folders), potentially allowing files to be shared between multiple projects. And you can define filters (working sets in Eclipse terminology) that determine what's shown in the UI. Switching between working sets is a one-click operation.
Based on these similarities, I don't see how your description sufficiently describes any way in which HomeSite is a superior product; there must be something else here that you're not telling us.
Although I really do like the PHP function outline feature.:)
The term scale in this context refers to the capacity for the software to meet growing requirements.
In other words, if you define a target performance metric and find that a single user can access the system at better or equal that speed, then a system can be said to "scale" if it still performs within that metric, on average, when 20, or 50, or 100, or whatever users are accessing the system.
Of course, due to the nature of computing systems, any system will hit a point where it will no longer scale to the requirements with the same hardware configuration. At that point we start talking about scaling upwards through hardware upgrades. But you can only upgrade hardware so far, at which point, again, the system will reach a hard limit on its ability to perform as required.
The next logical step is to scale through redundancy: If a system can, in whole or (more commonly, as in "multi-tier" web clusters) in part, run concurrently in multiple instances, then you can scale by adding more instances of the system or system components: Multiple web servers, multiple "back ends", multiple database servers, and similar. This kind of organic scaling can be, in practical terms, near-infinite if a system is designed well; for example, multiple mirrored web servers serving static pages will scale indefinitely, whereas a trading system requiring inter-process synchronization through a message-queue system will most likely not.
In scalability terms, efficient redundant clusters is the holy grail. It's the way Google scales, and it's how the core parts of the Internet scales.
In the context of this Slashdot story, since the poster faces limited possibilities for investing in expensive hardware, he might consider going for the "many cheap boxes" route, if his Microsoft-dominated infrastructure permits it.
He only said that those 1-megabyte messages negatively affected the average, not that they could be passed with anything approaching "near-real-time" speed.
As the other poster points out, the quote has nothing to do with bitterness. For more information about Dick's trash sensibilities, see Alexander Star's The God In The Trash: The Fantastic Life and Oracular Work of Philip K. Dick (The New Republic, 1993-12-06), the finest essay-length biography of Dick I have had the pleasure of reading.
"A spray can of Ubik," the girl answered, "is a portable negative ionizer, with a self-contained, high-voltage, low-amp unit powered by a peak-gain helium battery of 25kV. The negative ions are given a counter-clockwise spin by a radically biased acceleration chamber, which creates a centripetal tendency to them so that they cohere rather than dissipate. A negative ion field diminishes the velocity of anti-protophasons normally present in the atmosphere; as soon as their velocity falls they cease to be anti-protophasons and, under the principle of parity, no longer can unite with protophasons radiated from persons frozen in cold-pac; that is, those in half-life. The end result is that the proportion of protophasons not canceled by anti-protophasons increases, which means -- for a specific time, anyhow -- an increment in the net put-forth field of protophasonic activity... which the affected half-lifer experiences as greater vitality plus a lowering of the experience of low cold-pac temperatures."
Also, the comment about Dick's ideas infusing The Matrix is true as far as it goes, but misses one important point. Dick was an SF writer firmly grounded in the field, and would never have made as obvious and asinine mistake as violating the Second Law of Thermodynamics the way The Matrix's idiotic "humans as batteries" backstory does.
This is the guy who at one point used the phrase "negative ions" in a story.
If anything, Dick is a writer of speculative fiction. Science never figures prominently in his stories in the same way it does in the hard SF works of Clarke, Niven, Bear etc., and for good reason; while Dick was keenly interested in technology (his works are littered with characters strangely ranting about the inner workings of radios, cars, etc.), he did not have the mind of a visionary technologist, and at heart he was always a philosopher. Dick wrote incessantly about the nature of reality, but it was almost never about atoms and quarks, and almost always about the human experience.
In this Dick has much in common with Vonnegut, Brunner, Disch, Sturgeon, Lem, Bester, Orwell, the Strugatsky brothers, and many others who sits on the thin, mostly political line between mainstream literature and science fiction. Some, like Vonnegut and Lem, have long been embraced by the literati, and Dick would have been amazed and thrilled about the extent to which he has, in later years, been critiqued and accepted by the mainstream as a genuinely visionary thinker.
One of my many favourite PKD quotes, one that illustrates how well he uses future technology as commentary on the so-called human condition, follows.
The door refused to open. It said, "Five cents, please."
He searched his pockets. No more coins; nothing. "I'll pay you tomorrow," he told the door. Again he tried the knob. Again it remained locked tight. "What I pay you," he informed it, "is in the nature of a gratuity; I don't have to pay you."
"I think otherwise," the door said, "Look in the purchase contract you signed when you bought this [apartment]."
In his desk drawer he found the contract; since signing it he had found it necessary to refer to the document many times. Sure enough; payment to this door for opening and shutting constituted a mandatory fee. Not a tip.
"You discover I'm right," the door said. It sounded smug.
From the drawer beside the sink Joe Chip got a stainless steel knife; with it he began systematically to unscrew the bolt assembly of his apt's money-gulping door.
"I'll sue you," the door said as the first screw fell out.
Joe Chip said, "I've never been sued by a door. But I guess I can live through it."
Please, call a name of ODBMS that supports a query language based on some algebra (like SQL based on the relational algebra) *AND* lets me persist objects of new classes without recompiling the schema (generally/practically without stopping the DBMS server).
Matisse, Caché and FastObjects are only some products that come to mind. Though I can't speak for products I'm not familiar with, I don't know of any mature ODBMS that requires a restart in order to catch schema modifications.
Then what's wrong was to support any query language aka SQL, OQL or XPath?
You're the one who brought it up.
If I want many, slightly-different-from-each-other tables then I have my reason for that.
Read up on the relational model and the term "normalization".
Granted, currently relational-like databases don't optimize the normalized forms very well -- leading to so-called database experts recommending denormalized tables and null columns for performance -- and combined with the tight relationship between logical and physical table layouts in such database products, which is further compounded by SQL's awkwardly literal join semantics, properly normalized layouts with lots of tables is often painful. But that's the fault of current implementations, not the relational model.
Interestingly, Caché's SQL implementation adds some proprietary syntactic sugar to do away with awkward joins: You can do things like select e.employer.stock.shareCount from employees e where symbol = 'MSFT', in lieu of the traditional natural join syntax, select si.shareCount from employees, stockInfo si where si.company_id = employees.employee_id and si.symbol = 'MSFT'. As C. J. Date and others have pointed out repeatedly, SQL sucks.
I am not sure about what's wrong you see with sequences, but as for assotiated arrays... Did you try nested tables?
Afaik, nested tables is another deprecated remnant of the ancient "object-relational" stuff in PostgreSQL, and probably for good reason. (If the PostgreSQL guys are reviving the OO-ish stuff for some application, that's interesting -- do you have a reference?)
What the world needs, though, is a true relational database -- which, I'd like to point out yet again, does not exist -- not more pollution of the relational space. The relational model is extremely powerful and based on fundamental mathematical principles, yet it is not widely, or well, implemented. An object database layered on the relational model would be even neater.
... What about a situation when IT has to extend their reports, which are implemented queriing across several SQL databases and they (reports) are not web-based (Oracle Reports?), to include to the query some information from Zope? Would ZODB support SQL - that wouldn't be a problem.
You're talking about a problem that Zope and the ZODB is not designed to solve. Certainly it would be nice if Zope could integrate more seamlessly with relational data, but the idea is to reap the benefits of writing a Zope app from scratch -- and dispense with the "legacy" stuff. If you need to slap a front end on an existing "legacy" Oracle sales database, consider a "legacy"-oriented tool like PHP or AOLserver.
At last. I'd like to ask the question: if ZODB is so good as a DBMS, then why there are so many attempts to improve it in situations when I need one (or all) of the following? -...
Because ZODB was created a few years ago, whereas relational-like databases such as PostgreSQL have had years to mature. ZODB is essentially the work of one person. If you need those features in Zope, I suggest you contribute to the ZODB project.
This thread is already pretty off topic and attached to an old Slashdot story, and a waste of energy besides, so I'm not going to continue responding.
The main practical difference between ODBMS and RDBMS is that ODBMS is good for object persistence, not for querying.
Please describe how an ODBMS is "not [good] for querying". There are several ODBMS implementations that have excellent query capabilities. There is nothing inherent in the model preventing it from being appropriate for querying, even ad-hoc querying.
ZODB does not support queries, and relies entirely on an indexing engine (ZCatalog) layered above it.
On the other side RDBMS is better to store arrays of data of the same structure (same relational model) - millions (even billions) of records in few (dozens) tables. RDBMS is not good to store few records each in billions of tables. That's why it requires OR-mapping for persisting arbitrary application objects, and that translation makes it work slower.
If your relational model requires billions of tables, you have designed it wrong. The difference between RDBMS and ODBMS models have nothing to do with size differences, but with the models themselves.
... in PostgreSQL relational model is implemented being based on a object model since the beginning, without OR-mapping
This still does not eradicate the impedance mismatch between objects and tables. Objects can be implemented in the relational model, and probably should, but modern database systems, PostgreSQL included, implement the model badly. To store object-like structures in PostgreSQL, you still have to map sequences and associative arrays to tables, for example. In short, you cannot implement a typical application object model in PostgreSQL without resorting to relational constructs such as many-to-many tables.
Coming back to the practical life, I see one of the main ZODB problems in a lack of ability of being integrated with legacy systems.
The phrase "legacy systems" implies a system that is using outdated and deprecated technology. If your goal is to integrate with such databases, use Zope's relational database support (Z SQL Methods etc.). What's the point in massaging a legacy system into being the persistence storage for Zope? It's like saying you have this 20+ old mainframe, and Zope is crap because it can't store its data in it. That's silly.
You seem to have sucked up the wrong kind of terminology. PostgreSQL is not a "legacy" system. That is not the issue.
But the main problem of ZODB - it reinvents the wheel. It must be implemented on a top of PostgreSQL since the beginning.
"Must" is a strong word. Why must the ZODB do the things you want? It already solves the problems it's designed to solve. This sounds like cognitive dissonance to me; it's seems to me that you're desperate to use your PostgreSQL database, even if it's not useful. Have you studied the internals of the ZODB? Can you honestly say that PostgreSQL would do a better job? Exactly which wheel does the ZODB reinvent? It's not an RDBMS. The only functionality overlap with PostgreSQL is its ability to store data persistence. But the data it stores is wildly different from the data models that PostgreSQL support.
1. First is that it re-implements an http listener. Alternatively Zope works with Apache through a sort of CGI (CGI? Today?). I'd rather use Zope with Apache through some sort of mod-zope, like Tomcat.
Zope's HTTP listener is optional. If you want to use a server such as Apache as the HTTP front end, use FastCGI (mod_fastcgi). Despite the name, though, FastCGI is not really CGI as you know it, although it does require that Zope is running separately from Apache.
However, Zope is a publishing engine mostly based around HTTP. Almost every part of Zope assumes that HTTP is on the client end. And that's all well and good, considering that HTTP is the core of the web. And it hasn't stopped the Zope people from supporting XML-RPC and other access methods.
2. Also, I don't like ZODB - another reinventing the wheel while there are good open source databases. Besides, ZODB is a sort of ODBMS...
The ZODB is an ODBMS: It's an object-oriented database management system. Zope is an object-oriented system and relies entirely on the underlying OO persistence characteristics of the ZODB system.
With an RDBMS, Zope would have been forced to add a significant translation layer between its object file system and the logical database. Such translation -- usually known as object-relational mapping -- incurs much performance overhead, and is potentially awkward, since it needs to bridge between two fundamentally different data models.
... while I think ODBMS is a techological dead-end, even more dead-end than RDBMS. ORDBMS is the only way to go, IMHO. Thanks to PostgreSQL, there is an open-source ORDBMS.
Whatever marketing hype it is you've been smoking, consider detox. The ORDBMS is an illusion. Ever used the classes and methods and polymorphism specified by ANSI SQL-99 (aka SQL 3)? No, you have not -- because nobody has implemented it.
Oracle stuffed Oracle 8 with half-baked OO stuff. DB2 has support for tree constructs and multimedia. PostgreSQL started with inheritance and "time travel" versioning, and since they dropped the latter you're left with an esoteric mechanism that's hardly a significant improvement on the relational model.
Oh, and are we really mature enough to be playing around with bad, underspecified, non-standard "object" stuff when in fact nobody really implements the relational model correctly yet and we are still tied to that terrible language, SQL? Not even PostgreSQL is a true relational database in the mathematical sense as invented (or perhaps discovered) by E. F. Codd.
It's true that the ZODB does not support the relational model, but it solves some very specific problems and does it well, unlike ORDBMS technology, which is mostly smoke and mirrors used to describe proprietary extensions to SQL.
Unfortunately, it's mot possible (or it's not documented) how to get rid off ZODB completely and to use PostgreSQL as the primary DB backend.
You can't get rid of the ZODB per se, but you can switch out the ZODB back end, the storage driver that handles the physical data storage. People have written database back ends that store the database as simple files and in BerkeleyDB databases. Don't think anyone has written a generic RDB-based storage implementation, though.
The big problem is the fact that the "and" is emphasized.
No, the big problem is that it's incorrectly written and typeset.
Not only is there a comma missing after "Bombadil", the titles are not emphasized correctly. Quotation marks or emphasis should be used to clearly demarcate the titles. Since the story text itself is in italics, the titles should be in roman (ie., upright) type to set them apart. The correct formatting and grammar, therefore, would be:
"... It puts four of his works in one, Farmer Giles of Ham, The Adventures of Tom Bombadil, Leaf By Niggle and Smith of Wootton Major."
Of course, this is probably asking too much from the average Slashdot editor geek type.
The slashes in those URIs are not part of the protocol prefix, mind you.
The protocol is specified with "ftp:" and so forth. The two slashes are part of the host name, so in the URL ftp://foo.bar,//foo.bar designates the host.
Windows uses backslashes (\\foo.bar) and calls such paths Universal Naming Convention, or UNC, names.
Sounds like you could use BTDownloadRoundRobin , a utility which rotates between several torrents, thus letting you painlessly seed multiple files, but not all at the same time.
For those not ready to upgrade to Linux 2.5, and for those on other platforms, there is Trickle, a userland traffic shaper for Linux, *BSD and Solaris. It works on a per-process basis (or on groups of processes to limit aggregate traffic consumption), does not require root-level access nor kernel patches, and is, of course, open source.
I have been using rsync quite a lot myself. There are a few problems with it, as a backup tool.
The permission thing. Having to map the user and group names is inconvenient. For one, you have to maintain those users and groups.
Change sets. There is no sense of history: I can't go back to a certain date and get a snapshot of the data as it was then. This is absolutely required in certain scenarios. Of course, you could rotate among several different target directories, just like you would rotate tapes, but that wastes disk space that you might not possess.
Interestingly, rdiff-backup solves this problem; rdiff-backup uses librsync for the file transfer and has a simple backup increment system, with rudimentary support for file obsolescence by age (in other words, if you delete a file in the source location, it won't be deleted in the backup until a certain date).
The root issue. It would be much nicer if there was a server component running as root, which permitted specific users to connect and backup files.
Incidentally, rsync seems to not care about file name character encoding, which is a big minus. The port of rsync to Mac OS X will not transfer files containing 8-bit characters (eg., accented characters, Scandinavian letters), barfing with an "operation not permitted"-style I/O error. It seems that the Mac OS X APIs want UTF-8 file names. A simple internal translation should work.
To do a true backup, you must copy permissions. To copy permissions, the target system needs to have the same UIDs and GIDs as the source system. This is hard to do on Windows and OS X. Typical tools such as rsync, Unison and rdiff-backup make no effort to solve this problem. Suggestions?
So you can buy a cheap barebones system + CPU in the US. But shipping such a system to Europe costs hundreds of dollars, price depending on weight and volume. Does anyone know where to buy the same stuff in Europe, eg. Norway/Scandinavia?
And if you think Virtual Light ripped off Snow Crash, go check the publication dates again.
I concur. According to isbn.nu,
Snow Crash was published in hardcover by Bantam Doubleday Dell on June 1, 1992. Virtual Light's hardcover came out through the same publishing house on September 1, 1993.
That's a span of 15 months. Subtract the time used to actually publish a book -- several months to edit, proofread, design cover, produce galleys, typeset, plan marketing -- and Gibson would probably have to have been on speed to pull off such a feat.
Slashdot Mirror
There's an interesting claim I have seen made: Apparently the late binding feature of object-oriented languages -- virtual methods in C++, any non-static method in Java -- works against branch prediction, effectively resetting the prediction state whenever such a call is made, because the target jump address must be resolved -- read from a memory location -- only at the time of the jump. If this claim is accurate, this means typical OO code is inherently slower to execute than non-OO code on modern processors. Of course, the problem will equally apply to any language that supports function pointers, and in particular to C programs "emulating" OO with structs and function-pointer tables.
In your example, you're not "changing the type of a", you're assigning a different value to the symbol a. In Python and other strongly-dynamically typed languages such as Ruby and Lisp, values, not symbols, have types.
Python is strongly typed -- it provides a powerful typing system and enforces typing rules -- and it's also dynamically typed, meaning that any symbol can assume any value, so type errors cannot be detected at runtime. A statically typed language, as the name implies, requires that symbols be declared as a specific type, and type rules will be enforced on syntax at compile time (statically-typed languages such as C++ and Java require additional runtime type checking due to their support for late binding support, ie. polymorphism).
There is at least one proposal for an optional, static type system for Python (something like symbol: type like Pascal). There is also a proposal, by the Zope Corp. people, for adding interfaces to the language.
True. And for the Eclipse discovery of the day: Eclipse Profiler Plugin. Amazing.
There's a filter to hide closed projects. Package Explorer > Filters > Closed projects.
A more appropriate candidate for nested projects, imho, is API/implementation/test separation, and other subset/layer dependency issues.
For example, let's say your framework project has an interface package and an implementation package. The two packages should be compiled into two different JARs. Client applications should only depend on the interface package, through the interface JAR. Similarly, nobody probably needs the test package, so shouldn't need to link to it, but the test package needs the intf and impl packages, and should be compiled into its own JAR. If you have an internal plug-in system, you might want a fourth package for those interfaces/classes.
With Eclipse you still can't do this, and you would have to divide the project into different projects, in this case intf, impl and test. You could do it easily with nested projects, however.
This is analogous to how Eclipse does things. Each project is a separate entity. A project can link to different parts of the file system ("virtual" folders), potentially allowing files to be shared between multiple projects. And you can define filters (working sets in Eclipse terminology) that determine what's shown in the UI. Switching between working sets is a one-click operation.
Based on these similarities, I don't see how your description sufficiently describes any way in which HomeSite is a superior product; there must be something else here that you're not telling us.
There's a PHP outline in Eclipse?
In other words, if you define a target performance metric and find that a single user can access the system at better or equal that speed, then a system can be said to "scale" if it still performs within that metric, on average, when 20, or 50, or 100, or whatever users are accessing the system.
Of course, due to the nature of computing systems, any system will hit a point where it will no longer scale to the requirements with the same hardware configuration. At that point we start talking about scaling upwards through hardware upgrades. But you can only upgrade hardware so far, at which point, again, the system will reach a hard limit on its ability to perform as required.
The next logical step is to scale through redundancy: If a system can, in whole or (more commonly, as in "multi-tier" web clusters) in part, run concurrently in multiple instances, then you can scale by adding more instances of the system or system components: Multiple web servers, multiple "back ends", multiple database servers, and similar. This kind of organic scaling can be, in practical terms, near-infinite if a system is designed well; for example, multiple mirrored web servers serving static pages will scale indefinitely, whereas a trading system requiring inter-process synchronization through a message-queue system will most likely not.
In scalability terms, efficient redundant clusters is the holy grail. It's the way Google scales, and it's how the core parts of the Internet scales.
In the context of this Slashdot story, since the poster faces limited possibilities for investing in expensive hardware, he might consider going for the "many cheap boxes" route, if his Microsoft-dominated infrastructure permits it.
He only said that those 1-megabyte messages negatively affected the average, not that they could be passed with anything approaching "near-real-time" speed.
As the other poster points out, the quote has nothing to do with bitterness. For more information about Dick's trash sensibilities, see Alexander Star's The God In The Trash: The Fantastic Life and Oracular Work of Philip K. Dick (The New Republic, 1993-12-06), the finest essay-length biography of Dick I have had the pleasure of reading.
- "A spray can of Ubik," the girl answered, "is a portable negative ionizer, with a self-contained, high-voltage, low-amp unit powered by a peak-gain helium battery of 25kV. The negative ions are given a counter-clockwise spin by a radically biased acceleration chamber, which creates a centripetal tendency to them so that they cohere rather than dissipate. A negative ion field diminishes the velocity of anti-protophasons normally present in the atmosphere; as soon as their velocity falls they cease to be anti-protophasons and, under the principle of parity, no longer can unite with protophasons radiated from persons frozen in cold-pac; that is, those in half-life. The end result is that the proportion of protophasons not canceled by anti-protophasons increases, which means -- for a specific time, anyhow -- an increment in the net put-forth field of protophasonic activity... which the affected half-lifer experiences as greater vitality plus a lowering of the experience of low cold-pac temperatures."
(From Ubik, 1969)This is the guy who at one point used the phrase "negative ions" in a story.
If anything, Dick is a writer of speculative fiction. Science never figures prominently in his stories in the same way it does in the hard SF works of Clarke, Niven, Bear etc., and for good reason; while Dick was keenly interested in technology (his works are littered with characters strangely ranting about the inner workings of radios, cars, etc.), he did not have the mind of a visionary technologist, and at heart he was always a philosopher. Dick wrote incessantly about the nature of reality, but it was almost never about atoms and quarks, and almost always about the human experience.
In this Dick has much in common with Vonnegut, Brunner, Disch, Sturgeon, Lem, Bester, Orwell, the Strugatsky brothers, and many others who sits on the thin, mostly political line between mainstream literature and science fiction. Some, like Vonnegut and Lem, have long been embraced by the literati, and Dick would have been amazed and thrilled about the extent to which he has, in later years, been critiqued and accepted by the mainstream as a genuinely visionary thinker.
One of my many favourite PKD quotes, one that illustrates how well he uses future technology as commentary on the so-called human condition, follows.
- The door refused to open. It said, "Five cents, please."
(From Ubik, 1969).He searched his pockets. No more coins; nothing. "I'll pay you tomorrow," he told the door. Again he tried the knob. Again it remained locked tight. "What I pay you," he informed it, "is in the nature of a gratuity; I don't have to pay you."
"I think otherwise," the door said, "Look in the purchase contract you signed when you bought this [apartment]."
In his desk drawer he found the contract; since signing it he had found it necessary to refer to the document many times. Sure enough; payment to this door for opening and shutting constituted a mandatory fee. Not a tip.
"You discover I'm right," the door said. It sounded smug.
From the drawer beside the sink Joe Chip got a stainless steel knife; with it he began systematically to unscrew the bolt assembly of his apt's money-gulping door.
"I'll sue you," the door said as the first screw fell out.
Joe Chip said, "I've never been sued by a door. But I guess I can live through it."
Matisse, Caché and FastObjects are only some products that come to mind. Though I can't speak for products I'm not familiar with, I don't know of any mature ODBMS that requires a restart in order to catch schema modifications.
You're the one who brought it up.
Read up on the relational model and the term "normalization".
Granted, currently relational-like databases don't optimize the normalized forms very well -- leading to so-called database experts recommending denormalized tables and null columns for performance -- and combined with the tight relationship between logical and physical table layouts in such database products, which is further compounded by SQL's awkwardly literal join semantics, properly normalized layouts with lots of tables is often painful. But that's the fault of current implementations, not the relational model.
Interestingly, Caché's SQL implementation adds some proprietary syntactic sugar to do away with awkward joins: You can do things like select e.employer.stock.shareCount from employees e where symbol = 'MSFT', in lieu of the traditional natural join syntax, select si.shareCount from employees, stockInfo si where si.company_id = employees.employee_id and si.symbol = 'MSFT'. As C. J. Date and others have pointed out repeatedly, SQL sucks.
Afaik, nested tables is another deprecated remnant of the ancient "object-relational" stuff in PostgreSQL, and probably for good reason. (If the PostgreSQL guys are reviving the OO-ish stuff for some application, that's interesting -- do you have a reference?)
What the world needs, though, is a true relational database -- which, I'd like to point out yet again, does not exist -- not more pollution of the relational space. The relational model is extremely powerful and based on fundamental mathematical principles, yet it is not widely, or well, implemented. An object database layered on the relational model would be even neater.
You're talking about a problem that Zope and the ZODB is not designed to solve. Certainly it would be nice if Zope could integrate more seamlessly with relational data, but the idea is to reap the benefits of writing a Zope app from scratch -- and dispense with the "legacy" stuff. If you need to slap a front end on an existing "legacy" Oracle sales database, consider a "legacy"-oriented tool like PHP or AOLserver.
Because ZODB was created a few years ago, whereas relational-like databases such as PostgreSQL have had years to mature. ZODB is essentially the work of one person. If you need those features in Zope, I suggest you contribute to the ZODB project.
This thread is already pretty off topic and attached to an old Slashdot story, and a waste of energy besides, so I'm not going to continue responding.
- The main practical difference between ODBMS and RDBMS is that ODBMS is good for object persistence, not for querying.
Please describe how an ODBMS is "not [good] for querying". There are several ODBMS implementations that have excellent query capabilities. There is nothing inherent in the model preventing it from being appropriate for querying, even ad-hoc querying.ZODB does not support queries, and relies entirely on an indexing engine (ZCatalog) layered above it.
If your relational model requires billions of tables, you have designed it wrong. The difference between RDBMS and ODBMS models have nothing to do with size differences, but with the models themselves.
This still does not eradicate the impedance mismatch between objects and tables. Objects can be implemented in the relational model, and probably should, but modern database systems, PostgreSQL included, implement the model badly. To store object-like structures in PostgreSQL, you still have to map sequences and associative arrays to tables, for example. In short, you cannot implement a typical application object model in PostgreSQL without resorting to relational constructs such as many-to-many tables.
The phrase "legacy systems" implies a system that is using outdated and deprecated technology. If your goal is to integrate with such databases, use Zope's relational database support (Z SQL Methods etc.). What's the point in massaging a legacy system into being the persistence storage for Zope? It's like saying you have this 20+ old mainframe, and Zope is crap because it can't store its data in it. That's silly.
You seem to have sucked up the wrong kind of terminology. PostgreSQL is not a "legacy" system. That is not the issue.
"Must" is a strong word. Why must the ZODB do the things you want? It already solves the problems it's designed to solve. This sounds like cognitive dissonance to me; it's seems to me that you're desperate to use your PostgreSQL database, even if it's not useful. Have you studied the internals of the ZODB? Can you honestly say that PostgreSQL would do a better job? Exactly which wheel does the ZODB reinvent? It's not an RDBMS. The only functionality overlap with PostgreSQL is its ability to store data persistence. But the data it stores is wildly different from the data models that PostgreSQL support.
Zope's HTTP listener is optional. If you want to use a server such as Apache as the HTTP front end, use FastCGI (mod_fastcgi). Despite the name, though, FastCGI is not really CGI as you know it, although it does require that Zope is running separately from Apache.
However, Zope is a publishing engine mostly based around HTTP. Almost every part of Zope assumes that HTTP is on the client end. And that's all well and good, considering that HTTP is the core of the web. And it hasn't stopped the Zope people from supporting XML-RPC and other access methods.
The ZODB is an ODBMS: It's an object-oriented database management system. Zope is an object-oriented system and relies entirely on the underlying OO persistence characteristics of the ZODB system.
With an RDBMS, Zope would have been forced to add a significant translation layer between its object file system and the logical database. Such translation -- usually known as object-relational mapping -- incurs much performance overhead, and is potentially awkward, since it needs to bridge between two fundamentally different data models.
Whatever marketing hype it is you've been smoking, consider detox. The ORDBMS is an illusion. Ever used the classes and methods and polymorphism specified by ANSI SQL-99 (aka SQL 3)? No, you have not -- because nobody has implemented it.
Oracle stuffed Oracle 8 with half-baked OO stuff. DB2 has support for tree constructs and multimedia. PostgreSQL started with inheritance and "time travel" versioning, and since they dropped the latter you're left with an esoteric mechanism that's hardly a significant improvement on the relational model.
Oh, and are we really mature enough to be playing around with bad, underspecified, non-standard "object" stuff when in fact nobody really implements the relational model correctly yet and we are still tied to that terrible language, SQL? Not even PostgreSQL is a true relational database in the mathematical sense as invented (or perhaps discovered) by E. F. Codd.
It's true that the ZODB does not support the relational model, but it solves some very specific problems and does it well, unlike ORDBMS technology, which is mostly smoke and mirrors used to describe proprietary extensions to SQL.
You can't get rid of the ZODB per se, but you can switch out the ZODB back end, the storage driver that handles the physical data storage. People have written database back ends that store the database as simple files and in BerkeleyDB databases. Don't think anyone has written a generic RDB-based storage implementation, though.
Witness the date, folks:
I tried twice. I bet it's my ungeeky signature. Yes, that must be it.
-- Which illustrates how badly formatted the story text in fact is. QED, really.
No, the big problem is that it's incorrectly written and typeset.
Not only is there a comma missing after "Bombadil", the titles are not emphasized correctly. Quotation marks or emphasis should be used to clearly demarcate the titles. Since the story text itself is in italics, the titles should be in roman (ie., upright) type to set them apart. The correct formatting and grammar, therefore, would be:
- "... It puts four of his works in one, Farmer Giles of Ham, The Adventures of Tom Bombadil, Leaf By Niggle and Smith of Wootton Major."
Of course, this is probably asking too much from the average Slashdot editor geek type.'Twas Beowulf , not Gilgamesh.
The protocol is specified with "ftp:" and so forth. The two slashes are part of the host name, so in the URL ftp://foo.bar, //foo.bar designates the host.
Windows uses backslashes (\\foo.bar) and calls such paths Universal Naming Convention, or UNC, names.
Sounds like you could use BTDownloadRoundRobin , a utility which rotates between several torrents, thus letting you painlessly seed multiple files, but not all at the same time.
For those not ready to upgrade to Linux 2.5, and for those on other platforms, there is Trickle, a userland traffic shaper for Linux, *BSD and Solaris. It works on a per-process basis (or on groups of processes to limit aggregate traffic consumption), does not require root-level access nor kernel patches, and is, of course, open source.
The permission thing. Having to map the user and group names is inconvenient. For one, you have to maintain those users and groups.
Change sets. There is no sense of history: I can't go back to a certain date and get a snapshot of the data as it was then. This is absolutely required in certain scenarios. Of course, you could rotate among several different target directories, just like you would rotate tapes, but that wastes disk space that you might not possess.
Interestingly, rdiff-backup solves this problem; rdiff-backup uses librsync for the file transfer and has a simple backup increment system, with rudimentary support for file obsolescence by age (in other words, if you delete a file in the source location, it won't be deleted in the backup until a certain date).
The root issue. It would be much nicer if there was a server component running as root, which permitted specific users to connect and backup files.
Incidentally, rsync seems to not care about file name character encoding, which is a big minus. The port of rsync to Mac OS X will not transfer files containing 8-bit characters (eg., accented characters, Scandinavian letters), barfing with an "operation not permitted"-style I/O error. It seems that the Mac OS X APIs want UTF-8 file names. A simple internal translation should work.
To do a true backup, you must copy permissions. To copy permissions, the target system needs to have the same UIDs and GIDs as the source system. This is hard to do on Windows and OS X. Typical tools such as rsync, Unison and rdiff-backup make no effort to solve this problem. Suggestions?
So you can buy a cheap barebones system + CPU in the US. But shipping such a system to Europe costs hundreds of dollars, price depending on weight and volume. Does anyone know where to buy the same stuff in Europe, eg. Norway/Scandinavia?
I concur. According to isbn.nu, Snow Crash was published in hardcover by Bantam Doubleday Dell on June 1, 1992. Virtual Light's hardcover came out through the same publishing house on September 1, 1993.
That's a span of 15 months. Subtract the time used to actually publish a book -- several months to edit, proofread, design cover, produce galleys, typeset, plan marketing -- and Gibson would probably have to have been on speed to pull off such a feat.
And Philip K. Dick is dead, alas.