Older blog entries for Fefe (starting at number 13)

openssl did link but had some problems. Now it passes the complete test suite. And we linked openssh. And boa. And GNU bash (with readline and history).

The diet libc is maturing quickly. Recently, we successfully linked busybox, ncurses, vim, openssl, fdisk, mount and umount against it. Olaf is moving forward nicely with the shared library loader, the pthreads appear to work fine,... I'm happy. Mandrakesoft has ported their installation floppies to it, saving lots of space in the process.

Olaf and I are thinking about starting a libstdc++ using libowfat as foundation. I wrote a few libowfat functions for this, and Olaf already did a test iostream cout that is just a hello world and it was below 3k although it contained buffering code!

I cleaned up the diet libc mess when cross compiling a little. I also added a wrapper for gcc, so now you can say diet gcc -o t t.c and it will add all the magic gcc options by itself. It will also work when you say diet sparc-linux-gcc -o t t.c and link against the sparc cross-compiled dietlibc.a. I hope that makes diet libc more accessible.

20 Mar 2001 (updated 20 Mar 2001 at 13:32 UTC) »

I'm driving to CeBIT tomorrow, so I released new versions of the diet libc and the embedded utils tonight. It's getting more complete by the day. Recent additions are crypt and get{pw,sp,gr}ent, so I can now link checkpassword against it - one of the few pieces of djb software that did not work until now.

I linked most of the services on www.fefe.de against the diet libc now, and the Apache is by far the largest remaining memory hog, so it needs to go. I need CGI, I need it to run in a chroot jail, and I need basic header rewriting capabilities. Let's see how far I get.

I am currently writing an article about MPLS for c't magazine, and they want it to be ready tomorrow noon. The text is largely ready, but I need to sketch some illustrations now.

1 Mar 2001 (updated 1 Mar 2001 at 22:41 UTC) »

gethostbyaddr works now, too. DNS is even uglier than I previously thought. When you query for an A record (i.e. you want to know the IP for a name), you get n DNS records back. The problem is, there is no length byte, i.e. you don't know how long each record is. Unless you have code that knows how to parse the data payload for each record type, that is!

No problem, you might think. When you ask for A records, you will only get A records in replies, right? Wrong! You can also get CNAME records. And maybe DNAME? DNSSEC records?

I wonder what bozo invented a protocol like that and had the nerve to write in the RFCs that DNS is designed to be extensible.

gethostbyname is working now, and it's below 5k of code. It does not do name qualification yet (i.e. try appending domains from /etc/resolv.conf), but it's a start.

21 Feb 2001 (updated 28 Feb 2001 at 23:35 UTC) »

One of the major parts missing from the diet libc is DNS, i.e. gethostbyname and friends. I'm working on the code now, and it ain't pleasant. One obstacle on the way was inet_aton, which is very lenient in what it accepts. The more I dig into the libc, the more dirt I find.

I renamed libfefe to libowfat so you can against it with -lowfat. OK, it's a weak joke, but it's better than libfefe. ;-)

libowfat has grown to include scan, fmt, uint, stralloc, str and open. unix and socket is in the works.

Anyway, the diet libc is now feature complete enough that I can compile and link non-trivial programs like gzip, lzop and bzip2 against it (with large file support). Combined with the new upx beta it is a very powerful tool for low memory situations like rescue floppies.

8 Jan 2001 (updated 8 Jan 2001 at 16:21 UTC) »

I decided to start reimplementing the djb library and place the result under the GPL. I have had several people ask me about licensing. Since I use the djb library in several other projects, and there has been trouble getting ncp into Debian (they would only ship it in the non-free section), this really is a thorn in my side.

Anyway, the reimplementation project's home page is at http://www.fefe.de/libfefe/. Yes, I know the name sucks. If you have a better one, please let me know. ;-)

So far, I only reimplemented the functions declared in byte.h. No much, but it's a start. Please help!

The more I do with the libc, the more I find that it stinks. And I don't mean the glibc implementation, although there is quite a lot about it that I find objectionable. The whole API stinks.

All this backwards compatibility crap, all the fake namespaces, tons of #defines, and then essential functionality like functions to convert an integer or double into a string portably is missing!

And I invite you to have a closer look at stdio. Most people are not aware of the hidden complexities of stdio. If any libc function returns a pointer, it is either pointing to some static buffer (yuck!) or the routine called malloc behind your back. Since GNU malloc alone weighs in at 20k, no wonder that there are no really small utilities. And did you notice that all the shell utilities use getopt? Another 10k. Using printf will reference complex floating point conversion routines and long long formatting support, which almost noone is using. Even worse, recent printf implementations even include wide character support and user definable types. All that bloat is sickening me.

I am really amazed how little thought people spend on their work. A friend recently complained about all the login processes on his box. Huh? Who would be so stupid to have login stay in memory for each logged in user? The answer is: PAM. And PAM is yet another glorious Sun invention. After my stomach had recovered, I wrote a small login replacement as part of the fgetty project. The cool part about my login is that it still offers pluggable authentication, only with a sane interface -- DJ Bernstein's checkpassword. Oh, and like most of my software, it strives to be minimal. login is 2772 bytes and login2 is 3012 bytes on my x86-linux box (login2 is the part of login that is executed by checkpassword, it runs as the user, not as root). Maybe there is a hope after all.

Today I took the time to add a few of my recent projects to Advogato. Maybe that will inspire some of you to contribute some code ;-)

4 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!