Older blog entries for Fefe (starting at number 7)

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.

glibc stinks. How can it be that statically linking an empty program creates a binary of over 200k size (after stripping)?! I don't get it.

Fortunately, reading the libc sources is quite instructive (I would say the libc 5 sources are easier to read), and so I started a new project today: diet libc. It just contains the bare minimum you need to link a typical libdjb program, i.e. the system call wrappers and malloc() and friends. There was some almost usable source code from Red Hat that I extended and ported to the glibc headers, and I included some malloc code from 1998 that I found on my machine from someone else. Isn't free software great? ;-)

Anyway, using that diet libc, I was able to make a 3k statically linked sln. The one from glibc is 800k on my machine. Why? Because glibc doesn't strip the binaries it installs. Ulrich Drepper thinks that disk space is not important. Well, to him, maybe.

Also, I released my ncp/npush/npoll rewrite using libdjb today. This code spreads like wildfire. Almost all unix users I know personally already use it. You might want to have a look at it, too.