Hi,
[email protected] wrote:
> there isn't the one answer that fits all situations.
>
> The goal in this respect is simplicity and maintainability.
Yup.
> 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.
In case of system routines like malloc() the seperation is not only
justifiable: it's obvious, at least to a degree. In general, any
routines that use syscalls would have to be excluded in the first
place :)
> Duplicate code *is*
> maintainable if you don't overdo it.
Yeah, and if it's fairly obvious where other copies would reside.
> 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.
I'm very much aware of that :)
> 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.
I don't know 'imsg', but reallocarray(3) is a clear example of a routine
that's useful to many diff programs, and should thus be externally
available.
> 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.
A modern solution would be to ditch archive-style libraries altogether
and store the individual objects in seperate files. Though while that
would certainly help against dependency hell, it wouldn't quite be a
guarantee of its elimination...
> Everybody has to learn POSIX anyway.
Not that POSIX can't have it wrong though... *cough*
> 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.
Of course not. Though if the set of library objects follows a consistent
naming scheme, and the manual pages are all there, it might not be so
bad.
The thing I'm really wary of is preprocessor macros. Even with a manual
page, I more than often find '$x expands to $y' to be a sign of
impending trouble. Especially if they're nested...
> It really depends on the situation, and the balancing act between
> abstration and duplication needs experience and taste, not rigid
> principles.
Depends on how you define 'rigid principles'. A set of good working
and organizational habits, based on experience, can certainly be
beneficial. As long as it doesn't turn our craft into a religion...
> P.S.
> There is no good reason to insult Todd
I don't know him, I might've heard of him once. Needless to say, the
insult obviously wasn't personal.
> for running spamd(8), which
> is a standard tool and less annoying than some others.
How do you find 'Hello, spam sender. Pleased to be wasting your time.'
anything but a grave insult to someone who takes the trouble to manually
send e-mail?
> 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.
I do appreciate that, and I don't complain much if messages get delayed
because of it.
But when I take the time and effort to not bother people with mangled
subject lines, and I'm just called a spammer and effectively dismissed,
then I call the responsible admin a jerkass for it.
'cause that's the feeling it evokes in me, even if it's through the
machine.
--schaafuit.
