Older blog entries for Fefe (starting at number 10)

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.

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.

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.

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 ;-)

Wow, diet libc has become quite a cool project! I just finished the ports to alpha, mips and arm and now it works on all major platforms that can run Linux in the first place!

I started a few other projects in the mean time. fgetty, for example. fgetty is a rewrite of mingetty to make it link against diet libc and produce a small binary. The memory footprint difference is staggering.

minit is planned to be a minimal init that is a merger of the ideas of sysvinit and daemontools. It can run even when the whole file system is read-only and you can still tell it to start a service after boot time. And: it has dependencies! I.e. when you start nfs, portmapper can be started automatically. And the static binary is only 7k!

I guess they are right. Size does matter...

Defcon was quite cool.

I got the impression that Americans have an alcohol problem, though. People went way overboard at Defcon, as though they were not permitted to drink at home.

And people in the US apparently earn way too much money. Everyone acted like he was the Chosen One. But it was very funny nonetheless. The friend who travelled with me even won a Sparc IPX. We were quite worried how the airport security people would react (they normally want you to "switch it on" before their eyes).

I visited Usenix Security, too, and I was impressed by the quality of the papers and talks there.

I decided to go to Defcon this year. Finally.

For some 7 years I wanted to go there but never got around to, but this year I am not going to delay it any more. And I will go to the Usenix security symposium. I am quite happy now ;-)

On a side note, I changed my ucspi-tcp IPv6 patch to add the man pages from an earlier version of ucspi-tcp that djb removed for some reason that I don't comprehend. The web is great for a lot of stuff, but it should not be the only source of documentation and the documentation should always also be included with the software package so you can put it on a floppy disk or tape and install it on some standalone machine somewhere remote.

And why do people use info to document smaller packages? Info is great for large monster projects like glibc and gcc, but come one, glibc should come with man pages! Currently, Linux users have to get the man pages from a different source than the libc thus leading to incomplete and partly even wrong documentation coverage.