Hi, there isn't the one answer that fits all situations.
The goal in this respect is simplicity and maintainability. Often, it is simpler to maintain two copies of similar code. For example, the libc and kernel implementations of malloc(3) and malloc(9) are distinct. Reacharound between kernel and userland sources is usually a bad idea, causing #ifdefs, confusion, and bugs, but not simplicity. Duplicate code *is* maintainable if you don't overdo it. When a new type of bug is found, OpenBSD developers have a habit of scanning the complete tree to see whether similar bugs lurk at other places, too. Often, it is simpler to create a library for functionality that has become stable enough and that has come into use at many places. For example, the imsg functions - see imsg_init(3) - were moved into libutil in 2010, after several years of development and stabilization. A smaller, more recent example is the reallocarray(3) family of functions in libc. But making something a library doesn't always simplify things. Layering and abstraction often increase complexity. Sooner or later, you detect duplication inside your library, so you make it use a library which in turn uses a library. CPAN style interminable dependency chains are not simplicity. Or just look at the maze of libraries in FreeBSD. Everybody has to learn POSIX anyway. But if you invent hundred additional interfaces abstracting combinations of functionality that you need here and there, people who want to read and maintain code suddenly have to learn 100 more interfaces. That is not necessarily simpler. It really depends on the situation, and the balancing act between abstration and duplication needs experience and taste, not rigid principles. Yours, Ingo P.S. There is no good reason to insult Todd for running spamd(8), which is a standard tool and less annoying than some others. Managing completely open mailing lists is a very difficult, a tiresome, and a thankless job, in particular for popular lists like the OpenBSD ones, and i'm quite glad the service has been running so smoothly all these years.
