Here we go again. Third edition of the discussing with a NetBSD developer serie.
Today, 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, called 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
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
Derniers commentaires