As my regular readers know, I often conduct perspective interviews with IT professionals as a counterpoint to our own Perl culture.
This week I'm interviewing a C programmer, Mark Miller, who is working on a new program that I'm sure you all will agree is quite exciting -- please do read on and then share your comments.
Scott: Mark, good of us to join us today. Now, before we get into too much detail about what your program does, I think our readers will agree we should be interested in your approach.
Besides, I don't want people to stop reading
after you tell them what you told me about your
idea!
Mark: (Laughing) Yes, well, I'm here to answer questions. Ask away!
S: Security is big now days, with C programming. Did you use the old string functions like strstr, or did you use the, length counted functions like strnstr?
M: Oh, I rolled my own set of string functions. The company I work for has a security toolkit which we've all put a lot of effort into, you see.
S: Fine. Fine. Jolly good. Which make system did you use?
M: Well, I looked at make, and ANT, and thought about adapting Sendmail's trice-deep nested system of shell scripts but rejected that because they actually rebuild from the start every time anyway, and finally, I settled on my own system...
S: Excellent, that's popular now days. I'm sure my readers will agree you've made the right choice there.
I understand the application is networked and requires authentication. Are you supporting PAM, and do you fall back on the old getpwent functions?
M: Well, to tell the truth, I don't think this is a very clean approach, contrary to much press, and other C programmers overwhelming agree with me here. Rather than calling the standard but overly simplistic POSIX functions to authenticate a user or treating PAM like a standard, which it is in the literal sense of the word, I chose to be neutral and portable about the whole affair. As such, I only support authentication daemons that interface authentication services that manifold together authentication schemes including networking protocols that make network transparent authentication schemes. This is the approach employed by Postfix with its support for Dovecot and Cygnus-SALS and I think it works quite nicely.
S: Very good, but let me try to understand this in terms my readers, which may not be experienced with such advanced development processes can understand. By talking to Cygnus-SALS and Dovecot and other authentication daemons, you're avoiding talking to PAM directly, otherwise you'd be too close to interfacing directly with Kerberos, and Kerberos is too close to interfacing with getpwent()?
M: Yes, correct. I feel the more abstraction, the better. Why should I have to worry about the syntax for calling getpwent() when other people have already implemented daemons that do this, already written in C++, with numerous FAQs on the 'net of how to install and configure them?
S: Good, good! Now, what strategy are you taking to reclaim memory? Purify, or are you using one of the many excellent garbage collectors for C?
No, garbage collection hasn't yet acheieved it's theoretical maximum efficiency by a margin of several fractions of a percent, so I'm holding out in favor of a reference counting scheme I devised just for this application.
S: Now that people know the technical details of you're leveraging IT, tell our readers what your program hopes to accomplishes, and is sure to accomplish, no doubt.
M: Well, I don't want to make it sound more complex than it is, but basically it's a network-enabled version of "Hello world".
S: Excellent! I'm sure we've all learned a lot from talking to you. I know I have. Thanks for being here in this coffee shop I sometimes come to. People like you are the future of IT!
M: Thank you for having me on your show.
