Interview with S.P. Zeidler

Here's the third edition of the "discussions with a NetBSD developer" series. This time, we had the chance to talk to S.P. Zeidler, admin and member of pkgsrc-releng.

NetBSDfr: For the readers who don't know you, can 
you shortly introduce yourself ?

spz: Hi, I'm S.P.Zeidler, call name Petra, also answers to spz 
or stargazer or Ophiuchi. I'm a member of the NetBSD admins 
team and of pkgsrc-releng. My archs are amiga, sparc64, amd64 
and i386. In other news, I'm Bavarian, mid-fortyish, female, married, 
2 cats, no kids.

NetBSDfr: Why did you choose to run NetBSD ? How 
long have you been using it ?

spz: It was the first free Unixoid system that ran on my Amiga, 
serpens, which has been running NetBSD since February 1995, i.e.
since NetBSD 1.0.

NetBSDfr: How did you become a NetBSD developer ?

spz: When the admins team was looking for more help, I got asked 
and didn't run away fast enough :-P

NetBSDfr: Do you have an idea of the time you spend working
 on the NetBSD project daily, weekly, monthly ?

spz: Half an hour daily at least, but depending on things to do; running 
up 20 hours over the course of a weekend happens quite easily. Both 
admins and pkgsrc-releng are demand driven, you get requests and you 
handle them, security updates to servers need to be done as vulnerabilities 
become known, etc etc. I don't do much programming, if I commit 
something that's usually a bug fix where I sufficiently hated the bug to 
unpack the zapper myself instead of just whining about it.

NetBSDfr: What is the job of a NetBSD admin ? How many admins 
are there ? How do you work alltogether ? How do you share the tasks you 
have to do ?

spz: In the abstract, keeping the servers of The NetBSD Foundation secure, 
up, and doing useful work. At a closer view, it's plain old
system administration with administration of services like eg mail thrown in.

There are currently 5 admins on admins rotation, which means doing a week 
of looking after user requests in turn, plus 6 more who do specialized tasks 
like site visits or do emergency repairs if a server or service acts up (like 
eg putting a stop to a mail loop).  We have a ticketing system (RT) that user 
requests go into; whoever takes a ticket is responsible for resolving it.

For non-user requests, eg mail setup and mail-filtering is done by
soda@, and tls@ is looking after hardware; I handle OS and package
installation and upgrades.

NetBSDfr: What is the hardware infrastructure of the NetBSD
project, in terms of hardware and software ? Where are they located
?

spz: We currently have two main sites, at ISC in Redwood City where
the public servers are, and at Columbia University in New York where
the TNF owned build cluster is. There is one lonely box in Sweden,
hosted by the Luleå Academic Computer Society, which provides data
backup services.

The servers are a comparably boring bunch of rackmount servers (no
fun retro archs at all, unless you count i386 ;), the newer ones
amd64 arch and the older ones i386, and they run NetBSD-4 or NetBSD-5
at present, seeing that I am currently installing new servers instead
of upgrading the remaining NetBSD-4 machines.

blog.NetBSD.org is a TNF system as of earlier today, and there will
be a new ftp and due to reshuffling, new www and mail servers
eventually too.

Thanks to everybody who donated funds and made the new machines
possible, and of course also thanks to the organisations that host
them.

NetBSDfr: As part of the pkgsrc-releng team, can you tell us
more about the way pkgsrc releases are organised ? How is a release
tested / validated ?

spz: Unlike releng for the OS, the pkgsrc-releng team does not
actually create the releases, it just maintains them. Pkgsrc releases
are done roughly quarterly, give and take a week, and get 'cut' after
one to two weeks of freeze period during which build and security
issues of packages get fixed while the pkgsrc infrastructure itself
is static. Build issues get found by the bulk builders, packages not
working right get found by community input (if not by their maintainers,
who usually use their packages themselves).

The main advantage of a maintained stable branch is that security issues
get point fixes, ie you get to replace just the affected package and
the rest stays at same version, which makes eg configuration
incompatibilities a lot less likely. For production servers, using the
stable branch of pkgsrc is definitely a good idea.

NetBSDfr: You told us there were no fun retro arch in the machines
administered by the project. I'm wondering then how are pkgsrc
releases built (if they are) for those retro archs ? Are the pkgsrc
releases cross-compiled ? Provided by third-parties ? Not built ?
Does it work the same way for NetBSD releases by themselves ? Are all
the "fun retro" archs versions cross-compiled ?

spz: NetBSD proper can be cross compiled, the framework exists, and
it's being used to provide binaries for all archs (see ftp.netbsd.orgs
/pub/NetBSD-daily, we don't just build formal releases :).

pkgsrc has a few packages that have a cross compilation framework, but
most don't, and there are several packages with a lot of dependants
for which creating such a framework would mean ripping out the entire
build system the package brings itself and redoing it, and redoing it
for every new version that comes out after it, unless one gets buy-in
by the people who create and maintain the software being packaged
itself.

One of the headache packages in that space is perl, and it's interesting
to see that there is now interest in a fully cross-compilable perl in
the perl community itself.

So how do binary packages materialize? Developers who have the hardware
bulk-build packages and upload them. You can read about the build
reports on the mailing list pkgsrc-bulk.

NetBSDfr : In your professional environment, do you work with
NetBSD ? How do you think we should promote NetBSD for wider use
within companies ?

spz: At my present job I don't work with NetBSB (yet); I'm currently
not responsible for internal IT and the customers have existing servers
to take care of, where a ninja change of OS is not entirely practical,
if occasionally very much desired. :-7 There is lately some pkgsrc, at
least.

In my experience, NetBSD gets used in general IT in companies where
the sysadmins knew NetBSD previously and appreciated it as a
"install - configure - runs" system of minimum ick factor.
The more people know and appreciate NetBSD, and the more practical
its use on production servers, the more use of that kind it will
see. Of course, many companies use NetBSD and have no idea that they
do so, since it's part of some "solution device" they use; these tend
to be boring from my point of view though, since they tend to be
rather black-box like. The makers of these devices will likely
differ. 

NetBSDfr: As a conclusion, can you tell us how you forecast NetBSD
future ?

spz: That's a hard one, especially as it depends a lot on 'chaotic'
nature events of, eg, one developer pulling something out of their
hat that proves to be a must have feature for an entire new class of
device, or others banding together to make a form of use that is now
possible but tedious to set up a snap drop-in; and in the long run,
the question where computing is going is also unclear.

I can tell you what I am hoping for, and that is for a NetBSD that is
small enough to allow the insertion of daring new ideas in -current,
and large enough to mature -current into a rock solid release track
system periodically; a project that generates ideas that may spread
into the common pool and isn't just a me-too with slightly different
wallpaper. That is why I'm spending my time on doing infrastructure,
at least.

Oh, and I want cool ARM based netbooks with ridiculously long battery
lifetime running NetBSD available soonish. The guilty parties will
hopefully get a move on :-P

Many thanks to Guillaume Lasmayous from NetBSDfr for his hard work in preparing, conducting and translating this interview.

See the original post at www.NetBSDfr.org