Slashdot Mirror

Deven writes "Computerworld is reporting that Oracle has just acquired Sleepycat Software (makers of the open-source Berkeley DB embedded database) for an undisclosed sum. Having previously acquired Innobase, Oracle is certainly taking a look at diversity."

Supp0rtLinux writes "According to this article over at Linux Devices and noted on here at NewsForge.com, Motorola has released a newer version of its A76x line of cellular phones. This newest release, the A768, boasts of open source softwares from Monta Vista Linux, Trolltech, and Sleepycat. The only downside is that it appears to only be available in China right now. And the older A760 released last August is still only available in Europe and Asia. Why are we in the U.S. always the last to get new cellular toys? The good news, though, is that with a Linux base and an integrated PDA and MS Office file compatibility, at least syncing this to either a Linux system or a Windows one should be fairly seamless. (A760 Review)"

At first, there was mbox, then there was Maildir, and Bill begat Outlook and .mbx. CaraCalla wonders if there is a better way to store mail than the way we currently store it today. I admit, with the changes that email has undergone over the past 5 years (changes in what is being sent, not necessarily in how it is sent), it may be time to reinvent the mail format. Read on for CaraCalla's analysis of the current mail options, and his thoughts on where we may go in the future. If you were to design your own MUA, how would you design its mail storage? CaraCalla asks: "Does anybody know a good, free solution for storing mail on unix hosts? The reason that I ask this question is my discontent with available techniques:

• mbox: There are problems with locking, corruption, access-times, and bloat.
• Maildir: Do you really want to clutter your system with millions of small files? That's waste of inodes, space (unless perhaps you use Linux/ReiserFS or SGi) and just try to open a Maildir with 1000+ mails and see how long it takes your favorite Mailprogram to only display the subjects.
• Cyrus: Basically the same as Maildir with database features.
• UW-Imap mbx: That's classical mbox with extensions allowing multiple access.
• Evolution: Basically mbox with database features.
• Windows clients: Typically some proprietary db-format. Pathetic.

But the thing that bugs me most is disk space. Typical inboxes are made of 5% to 10% of Text including Headers and HTML. The rest are BASE64- (or UU-) encoded pictures, word documents, zip archives and so on. The problem here is the encoding which wastes considerable amounts of space (at least one third).

Some ideas about the ideal mail-storage:

• One file per Mailbox-folder, allowing multiple folders per user. Should those files reside in one central location or in users Homedirs?
• Compression: Should messages be broken into pieces and the MIME-attachments stored separately (thus searching of the text parts would still be possible without decompressing the whole file)?
• File format: gdbm, Sleepycat db? Something new?
• Should the security model allow users to directly access their files, grep them, copy them around?
• Shared folders, virtual domains?
• Unicode support in folder names? Imap message-IDs, flags, useragent specific state-information?
• How would MTAs deliver mail? How would clients access? File-locking (NFS)?
• What about backwards-compatibility? Writing libmailstore (anyone)? adopting UW c-client?

Does my ideal mailstorage exist somewhere? Is somebody working on a project addressing this? Does anybody have some other hints? And please no mbox/Maildir flamewar!"

Chairman writes: "Sleepycat Software (disclaimer -- I work there) just released version 4.0 of Berkeley DB. This version adds support for replication, so apps can survive single- or multi-node hardware or software failures without interruption in service. With the interest in replication by users of MySQL and other SQL databases, an embedded engine that provides the same services might be interesting to Slashdot readers."

Chairman writes: "Sleepycat Software (disclaimer -- I work there) just released version 4.0 of Berkeley DB. This version adds support for replication, so apps can survive single- or multi-node hardware or software failures without interruption in service. With the interest in replication by users of MySQL and other SQL databases, an embedded engine that provides the same services might be interesting to Slashdot readers."

Boban Acimovic writes "According to this story on the Yahoo Financial News", IBM is going to buy Informix Database Software for $1 billion in cash. The main players in database leader struggle will be Oracle and IBM after this acquisition." That's in the commericial space - obviously SleepyCat, PostGres and MySQL and others aren't going away. And it appears that the other parts of Informix will be staying around as a seperate biz, so we should continue to see their support for OSS ^[?] .

Paul Gear asks: "I'm wanting to create a database using Berkeley DB that includes a lot of textual information, and because of the bulk of the data and its obvious compressibility, I was wondering whether it was possible to have the DB libraries automatically compress it at the file level, rather than me compressing each data (rather small) item before putting it in (which would result in much less gain in compression). Section 4.1 of the paper "Challenges in Embedded Database System Administration" talks about automatic compression, but that is the only place in the documentation that it is mentioned. Can anyone point me in the right direction?"

el_nino writes "It seems glibc 2.1 has been withdrawn because of a license problem. A mail from Adam J. Richter to the bugs-glibc mailing list: "The source files in the db2 section of glibc-2.1 point to a nonexistant file named "LICENSE." The files are apparently written by Sleepycat software, and the copying conditions found on www.sleepycat.com for this package are the BSD copying conditions with the advertising restrictions that FSF claims are incompatible with the GPL." The glibc-2.1-README on ftp.gnu.org says: "glibc-2.1 has been (temporarily) removed, until some political issues are worked out." " Zack Weinberg wrote with an update: I'd like to correct some factual errors in the story you posted on Slashdot regarding glibc 2.1 being pulled from ftp.gnu.org. The pull has nothing to do with the license conditions for db2. There is some disagreement over whether the BSD license is compatible with the GPL, but FSF's official stance is that they are. The license for db2 is clearly stated in an appendix to the libc manual (see manual/contrib.texi).

glibc 2.1 has been pulled since it cannot be compiled with gcc 2.8 and this conflicts with FSF policy. We are working with RMS to resolve the issue. In the meantime, glibc 2.1 remains available from sourceware.cygnus.com and its mirrors.

zw