uClibc versus eglibc

This is a post about differences between uClibc and eglibc libraries. Namely, OpenWRT can be built on either of those two libraries with the default being uClibc, so the question one might ask is what's the difference between those libraries and why uClibc. I have to say that I'm not affiliated with neither of those, and what I wrote here is purely my personal opinion based on the information I managed to find on the Internet. I suppose that you know what C standard library is, what is its purpose and that the default C library on desktop and server Linux is glibc.

First, both eglibc and uClibc were developed with the intention of having a small footprint and thus to be suitable for use in embedded devices. glibc is a huge library that wasn't well suited for that purpose. Yet, those two libraries differ in a way they try to achieve that purpose.

eglibc

eglibc, or embedded glibc, was developed with the intention of being source and binary compatible with glibc. That means that isn't necessary to recompile existing binary applications compiled for glibc in order to be possible to run them on eglibc.  On the other hand, since it is source compatible with glibc, that means it is possible to recompile the source without any modifications. Yet, according to FAQ on eglibc page, eglibc development is stopped, and all embedded development will be done directly in glibc tree. This was announced on July 20th, 2013. That also means that almost all patches from eglibc will be ported to glibc. You can find more information here about the patches that are not going to be ported back.

What might confuse is that the newest eglibc release is based on glibc 2.19 which was released in April, 2014, a year after announcement that eglibc development will stop. But, this is according to the plan of phasing out separate eglibc tree. Also according to the plan, this is a last branch. All the branches will be maintained as long as the base glibc versions are maintained.

In June 2014 Debian announced that it's going to switch back from eglibc to glibc due to the changes in the governing structure of GLibc project. The reason for the change is that Ulrich Drepper left RedHat.

uClibc

uClibc, on the other hand, was developed with the intention to be source compatible only, i.e. no binary compatibility and thus binary programs compiled for glibc (or eglibc) have to be recompiled. uClibc is actively maintained even though the latest release is from 2012.

Conclusion

So, what is the conclusion? The conclusion is that if you don't need to be binary compatible, you should use uClibc  on OpenWRT. After all, all the binary packages on OpenWRT's site were compiled against that library. If binary compatibility is important to you, then glibc is the way to go. Unfortunately, since in OpenWRT there is eglibc and not glibc, you have to go eglibc route. Note that this also means you'll have to recompile all the sources for OpenWRT since you'll not be able to use precompiled binary packages!

Configuration management...

Anybody that ever administered more than few machines knows how hard it is to keep them maintained. Especially when you have a mix of different operating systems, and I mean different like Windows, Linux, AIX, HP-UX, etc. For that purpose many different configuration management applications were written, but there is no perfect solution. In case you are running Windows environment, then I have to admit that Active directory, along with several supporting tools is actually very good tool. On the Unix scene, there is much more diversity and, apparently, not such a good solution.

I stubled upon this blog post that compares different CM applications, most notably puppet, cfengine and bcfg2. It turns out that in comments section you'll find info and links to a lot more, e.g. cdist, chef, and many others.

Finally, I looked on Wikipedia while writing this blog post and found that there is a page devoted to the comparison of different CM application. I have to admit that Wikipedia is really becoming an ubiquitous source of information, despite occasional inaccuracies.

Evolution & Thunderbird

I can not describe how much Evolution annoys me! I'm using it for years, maybe 10 or so by now, and I can say with quite a bit of a confidence that it's full of bugs, at least on Fedora, and there was no release in past few years that didn't have some quirks that made me go mad! And today, it happened that it didn't want to create a meeting within a Google calendar with a usual unhelpful error message about failed authentication. To make things even more weird, it did show my available calendars on Google, and that requires authentication so it should work! After some searching on the Internet I found workaround that includes removing calendars from Evolution and re-adding them back again. This, by itself, made me closer to look for an alternative and to switch. Anyway, I started to remove all Google calendars from Evolution, but then, removing some didn't work!? The ones that were turned off because I didn't provide password for them. Even restarting Evolution didn't help. What helped in the end was that I changed username and afterward removal was successful!

The reason I'm using Evolution for so many years was that it had integrated calendar with mail client, todo lists and memos. I need at least calendar function along with a mail client. I'm already using Thunderbird but as a secondary mail client for some unimportant mail accounts and I know that it progressed quite nicely, and more importantly, it has Calendar extension. So, I started contemplating about switching mail client NOW! Well, everything OK except that I have huge mail archives stored in Evolution and I have to import them into Thunderbird. It turns out there is no migration wizard and that it has to be done manually. Then, it turned out that Thunderbird uses Mbox format, while Evolution uses Maildir format (it also used Mailbox until a year or so ago).

In essence, Mbox uses one file for all mail messages, while maildir uses one file per message. Maildir has many advantages over Mailbox and thus has become preffered way of storing mail messages on a file system. One reason I want maildir is that I'm doing backups and when one mail message is stored in a mbox (which by itself is huge file containing many messages) backup process will copy the whole file again.

Anyway, judging from the information I found on the Internet this is a long requested feature in Thunderbird. Thunderbird supports pluggable mail stores since version 3.1, but maildir format is not planned before version 11. In the end, I decided to wait a bit more and then to switch to Thunderbird.

Update

I forgot to mention one more bug. When I try to save existing calendar into ical file the evolution simply crashes, and this is 100% repeatable. I discovered this when I decided to clean up all the old calendars from evolution, but first I wanted to save them, just in case.