Wrong address! I mean OOo has never been designed for professional text authoring. All OOo is doing is just mimicking MS Office, which was designed for Joe Six Pack. If you remember, Word perfect was designed for professional writers.
If you really want reveal codes then you should use TeX. I specially recommend you to use LyX - excelent WYSIWIG environment for editing in TeX (actually LaTeX) code.
How about the changes coming in 2.6 (like xfs support built in)?
XFS is a good example of journalling filesystems. But how about filesystems like Coda, AFS and Intermezzo, a new generation of networking (actually - distributed) filesystems allowing disconnected operations?
Metadata is very application specific and most of filesystem are agnostic about it. Typically it must be handled by another layer on a top of FS.
Often that layer is a DB - database. I suggest you to try ZODB, database in Zope, it's very good to handle files as documents - with many unified metadata about files.
Another good example to study is Subversion, which is revisionining/versioning metadata-management layer on a top of a regular FS.
You may research and find some software implementing a layer (on a top of a regular FS) specially designed to handle MP3 playlists. But again, that would be a layer on a top of FS, not a filesystem by itself.
... which is a very, very good thing in cases when you *DON'T WANT* users to switch to and watch screens and windows of each other. But if you *WANT* them to do so - just disable the password checking in the xscreensaver.
Well, it's not too late to fix it then. Why not open source of People Soft? Or even better - why not GPLize them? That's the best way to shrink the market of Oracle and SAP competing ERP products. As for a profit: I guess JDE's business model is based on support, not on licensing, anyway.
Until then I prefer to use Unix word for Unix-certified systems. That's why I call BSD as BSD and Linux as Linux. What's wrong to call things as they are actually, not as they are wanted to be called by the marketing department in some commercial company?
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.
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).
ZODB does not support queries, and relies entirely on an indexing engine (ZCatalog) layered above it.
Then what's wrong was to support any query language aka SQL, OQL or XPath?
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.
I might exaggerated with billions of tables, but one of major differences between object and relations databases (when it comes to practical issues) is still related to sizes. I can lean my models to specific model (or implementation) limitations of a particular database, but that is not exactly what I want to do as an application designer. If I want many, slightly-different-from-each-other tables then I have my reason for that. Mixing all such tables to one table (with another one for "generic" attributes) is a sort of generic programming which is not good in RDBMS as the relational algebra doesn't reflect it well and thus an aplication has a problem of queriing from such "generic" database.
ODBMS lets me use inheritance, but as I mentioned above, there is no good, algebra-supported queriing against inheritance.
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.
I am not sure about what's wrong you see with sequences, but as for assotiated arrays... Did you try nested tables? In short, object model in PostgreSQL is not perfect yet (although, they are working on it to improve and they have a very good progres in it!), but if you know such limitations then you can minimize a possible OR-mapping and posiible usage of M-2-M tables. The good new is that in PostgreSQL you sacrifice less than in other ORDBMS, and that's b/c the object model in PostgreSQL is better implemented than in other ORDBMS: all schema objects are already classes.
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.
Let me define the "legacy" term. It's like who comes first. Usually SQL-based applications are already designed and work, while web applications are developed later and has to adopt. Most likely a "legacy" application has some other reasons that some part of the technology cannot be changed when we have to integrate it with new, web-based applications. 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.
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? -
arbitrary depth of the folder tree (try it is as deep as 1000);
very frequent (massive) changes in the folder tree (i.e. inventory in a big warehouse);
Last time I worked in ATT I've met Mr. Stroustrup there. If ATT owes Stroustrup (does he work there or not?) and he owes C++ (is he the inventor of C++ or not?) *and* the ownership relation is transitive (this part could be more difficult to agree) then ATT owes C++. Sort of.
doesn't that mean that more people are _less_ likely to make an ethical AI
Correction: Americans are less likely to make an ethical AI. Fortunately, US laws are not international and 97% of people can make ethical AI without any problems.
I guess, counting the fact that in few decades AI will take over the world, by the time this patent will be expired, the whole world will be diveded into ethical countries and US.
The main practical difference between ODBMS and RDBMS is that ODBMS is good for object persistence, not for querying. Despite indexing, arbitrary queries (ad-hoc, based on partially know structured context) in Zope are very weak (and they will be always weak until ZODB will become a real DBMS project). To make power queries I need some algebra (like relational). Object model doesn't have such. Perhaps ZODB should do the trick opposite to a typical OR-mapping in RDBMS - it should map persistent object to virtual relations based on available information about relations between persisted objects. ZSQL helps a bit but not really yet.
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.
ORDBMS is supposed to combine both benefits and solve both disadvantages. In practice, all commercial ORDBMS I know (i.e. Oracle) have object layer on a top of relational model, hiding such OR-mapping inside, but still suffering from slow translation. PostgreSQL is an exception (is it b/c it's not commercial?) - in PostgreSQL relational model is implemented being based on a object model since the beginning, without OR-mapping. In PostgreSQL everything is obejct of some class. And as far as I know inheritance is not dropped and actively supported and actively developed further.
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. As for now it is possible to add an external relational datasource to ZOPE (not ZODB) applications. But it is not easy to give the access for exisiting ZODB content to backend legacy applications in a same way as I would do with RDBMS (or ORDBMS). RDBMS is a very important part of a real life and it will be so longer than perhaps a life of ZODB project.
But the main problem of ZODB - it reinvents the wheel. It must be implemented on a top of PostgreSQL since the beginning.
You're right. All they need is Microsoft products.
Seriously, Microsft's success is an excellent demostration of how useless are perfect functionality and quality. I wouldn't point to any flame between *n*x and windows. Just consider how perfect Lotus Notus is and where it is now. Compare it with Office.
Hmm... That reminds me another bad example: I subscribe for a commercial mail-list (product updates, corporate news or something) on your web site and put my address wrong. I guess you'll pay for it.
That's why I keep saying: From/To RFC822 fields are not enough. We need PKI and we have to sign our email messages with a recognizable key to make messages TRACEABLE. Then and only then some law can be applied.
I guess "like everyone else" includes US. And in US they have a choice: to steal it or to buy it. That's exactly i wanna in Canada: they choice to steal it or to buy it. Now we don't have such choice: we have to steal it.
Without a good knowledge of maps most of Americans will try to look for Tbilissi (a capital of former Soviet Republic Georgia) somewhere on their own East Cost.
And the ITMS is, as you probably know, all tangled up in complicated European licensing issues - there's no European equivalent for the RIAA and even within single countries, the labels can't seem to agree on a common policy.
I thought Canada must have transparent copyright laws with USA. No?
By the way, why doesn't Twisted have "resemblance" with some of Jabber-server for its IM? IMHO new IP protocol will be re-implementing the wheel. Moreover, the implementation of proprietary IM protocols while ignoring the most famous open-source IM protocol (Jabber) should be considered as a shame for any open-source project, don't you think?
Anyway, I dislike the concept of re-implementing such protocols as SSH - it must be very secured, that's why I trust more to OpenSSH (and its libraries). Again, in embedded systems there might be no place for OpenSSH, but in "real world"... You've got a point.
To be honest, there are two things I don't like in Zope.
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.
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, 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. 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.
Apart of that Zope is well focused on a web-based content-management - right as it should following the Unix path:)
I've checked Twisted before makeing my choice for Zope. I found it as a sort of new OS, just without kernel. It can work well for embedded systems: imagine jsut kernel and twisted to do everything!
However the Unix way is oppositely different: make many small servers/applications/filters each doing its small function, but doing it very well. In case of twisted I found both web templates and instant messaging rather primitive, comparing to Zope and Jabber. And I don't see any benefits to keep inside the same application all of them: Web, IM, SSH. If I cannot answer to myself "why?" then I cannot recommend it to my clients.
By the way, Zope is also very big, comparing to Apache, which is just a core listener and static file service. However, the main problem with Apache is exactly in syndication of various information sources into pages in a way when such syndication is integrated with the overall web-server management. Check for typical problems in user and access management with Apache. Zope solves it for the price of making bigger. But as a developer I agree to pay that price as it gives me the integration around the same core thing: web-based information management as I get excelent quality for that price. In case of Twisted I have to pay even more price of complexivity for... for what? For having gathered together often unrelated services? Why? Again, I know when I have an answer for "why" question - in embedded systems. But it's different market than Zope is positioned on.
Slashdot Mirror
The only one I know that is missed in Gnumeric is a support for ActiveX. Although, I don't know if you want to call it a "missed feature".
If you really want reveal codes then you should use TeX. I specially recommend you to use LyX - excelent WYSIWIG environment for editing in TeX (actually LaTeX) code.
XFS is a good example of journalling filesystems. But how about filesystems like Coda, AFS and Intermezzo, a new generation of networking (actually - distributed) filesystems allowing disconnected operations?
Often that layer is a DB - database. I suggest you to try ZODB, database in Zope, it's very good to handle files as documents - with many unified metadata about files.
Another good example to study is Subversion, which is revisionining/versioning metadata-management layer on a top of a regular FS.
You may research and find some software implementing a layer (on a top of a regular FS) specially designed to handle MP3 playlists. But again, that would be a layer on a top of FS, not a filesystem by itself.
Well, it's not too late to fix it then. Why not open source of People Soft? Or even better - why not GPLize them? That's the best way to shrink the market of Oracle and SAP competing ERP products. As for a profit: I guess JDE's business model is based on support, not on licensing, anyway.
Until then I prefer to use Unix word for Unix-certified systems. That's why I call BSD as BSD and Linux as Linux. What's wrong to call things as they are actually, not as they are wanted to be called by the marketing department in some commercial company?
1. It doesn't load like Unix: I don't see any standard compliance in startup scripts.
2. It doesn't run like Unix: at least from the end-user prospective Quartz/Aqua is not X11.
3. You forgot one more important aspect: it's a big difference to program for OSX and for Unix.
So, it's not Unix.
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).
ZODB does not support queries, and relies entirely on an indexing engine (ZCatalog) layered above it.
Then what's wrong was to support any query language aka SQL, OQL or XPath?
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.
I might exaggerated with billions of tables, but one of major differences between object and relations databases (when it comes to practical issues) is still related to sizes. I can lean my models to specific model (or implementation) limitations of a particular database, but that is not exactly what I want to do as an application designer. If I want many, slightly-different-from-each-other tables then I have my reason for that. Mixing all such tables to one table (with another one for "generic" attributes) is a sort of generic programming which is not good in RDBMS as the relational algebra doesn't reflect it well and thus an aplication has a problem of queriing from such "generic" database.
ODBMS lets me use inheritance, but as I mentioned above, there is no good, algebra-supported queriing against inheritance.
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.
I am not sure about what's wrong you see with sequences, but as for assotiated arrays... Did you try nested tables? In short, object model in PostgreSQL is not perfect yet (although, they are working on it to improve and they have a very good progres in it!), but if you know such limitations then you can minimize a possible OR-mapping and posiible usage of M-2-M tables. The good new is that in PostgreSQL you sacrifice less than in other ORDBMS, and that's b/c the object model in PostgreSQL is better implemented than in other ORDBMS: all schema objects are already classes.
Let me define the "legacy" term. It's like who comes first. Usually SQL-based applications are already designed and work, while web applications are developed later and has to adopt. Most likely a "legacy" application has some other reasons that some part of the technology cannot be changed when we have to integrate it with new, web-based applications. 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.
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? -
Last time I worked in ATT I've met Mr. Stroustrup there. If ATT owes Stroustrup (does he work there or not?) and he owes C++ (is he the inventor of C++ or not?) *and* the ownership relation is transitive (this part could be more difficult to agree) then ATT owes C++. Sort of.
Correction: Americans are less likely to make an ethical AI. Fortunately, US laws are not international and 97% of people can make ethical AI without any problems.
I guess, counting the fact that in few decades AI will take over the world, by the time this patent will be expired, the whole world will be diveded into ethical countries and US.
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.
ORDBMS is supposed to combine both benefits and solve both disadvantages. In practice, all commercial ORDBMS I know (i.e. Oracle) have object layer on a top of relational model, hiding such OR-mapping inside, but still suffering from slow translation. PostgreSQL is an exception (is it b/c it's not commercial?) - in PostgreSQL relational model is implemented being based on a object model since the beginning, without OR-mapping. In PostgreSQL everything is obejct of some class. And as far as I know inheritance is not dropped and actively supported and actively developed further.
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. As for now it is possible to add an external relational datasource to ZOPE (not ZODB) applications. But it is not easy to give the access for exisiting ZODB content to backend legacy applications in a same way as I would do with RDBMS (or ORDBMS). RDBMS is a very important part of a real life and it will be so longer than perhaps a life of ZODB project.
But the main problem of ZODB - it reinvents the wheel. It must be implemented on a top of PostgreSQL since the beginning.
See the boss of your boss, make the deal with him and together with him fuck your boss 10 times by 5 pm Friday afternoon.
You're right. All they need is Microsoft products.
Seriously, Microsft's success is an excellent demostration of how useless are perfect functionality and quality. I wouldn't point to any flame between *n*x and windows. Just consider how perfect Lotus Notus is and where it is now. Compare it with Office.
That's why I keep saying: From/To RFC822 fields are not enough. We need PKI and we have to sign our email messages with a recognizable key to make messages TRACEABLE. Then and only then some law can be applied.
I guess "like everyone else" includes US. And in US they have a choice: to steal it or to buy it. That's exactly i wanna in Canada: they choice to steal it or to buy it. Now we don't have such choice: we have to steal it.
I can do that and I am not an American. 90% of my friends are not Americans and they also can differentiate American states.
The trueth is that most of Canadians know well USA. Most of Americans think about Canada as "Great White".
And by the way, most of Canadians I know don't call Americans stupid. Just "they are even less lucky than we are from the educational prospective".
Without a good knowledge of maps most of Americans will try to look for Tbilissi (a capital of former Soviet Republic Georgia) somewhere on their own East Cost.
I thought Canada must have transparent copyright laws with USA. No?
I doubt it will help us, Canadians, to shop music on iTunes.
- don't use a cell phone, regular phone line or post mail - visit your bad-partners a person;
- never use Internet whatsoever;
- don't use credit cards or checks - pay only cash;
- don't use any name-based tickets on any transports: airplanes, train, bus-express; instead walk or drive; riding a bike or a scateboard is ok;
- eat only a fast-food; a restourant waiter can memorize you;
- don't buy any house and don't rent any appartments; motels for cash are fine;
- don't... don't... don't... don't...
Man! isn't it easier just to be a good guy?Anyway, I dislike the concept of re-implementing such protocols as SSH - it must be very secured, that's why I trust more to OpenSSH (and its libraries). Again, in embedded systems there might be no place for OpenSSH, but in "real world"... You've got a point.
To be honest, there are two things I don't like in Zope.
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.
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, 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. 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.
Apart of that Zope is well focused on a web-based content-management - right as it should following the Unix path :)
By the way, what's so good about Silva? What can it give me that CMF cannot?
However the Unix way is oppositely different: make many small servers/applications/filters each doing its small function, but doing it very well. In case of twisted I found both web templates and instant messaging rather primitive, comparing to Zope and Jabber. And I don't see any benefits to keep inside the same application all of them: Web, IM, SSH. If I cannot answer to myself "why?" then I cannot recommend it to my clients.
By the way, Zope is also very big, comparing to Apache, which is just a core listener and static file service. However, the main problem with Apache is exactly in syndication of various information sources into pages in a way when such syndication is integrated with the overall web-server management. Check for typical problems in user and access management with Apache. Zope solves it for the price of making bigger. But as a developer I agree to pay that price as it gives me the integration around the same core thing: web-based information management as I get excelent quality for that price. In case of Twisted I have to pay even more price of complexivity for ... for what? For having gathered together often unrelated services? Why? Again, I know when I have an answer for "why" question - in embedded systems. But it's different market than Zope is positioned on.
Other guys are mentioning many projects, but I want to emphsize on three project, IMHO the most important to illustrate the power of Python: