NetBSD 1.6.2 is a maintenance release that provides the following updates relative to 1.6.1:
A number of security issues have been fixed.Some performance fixes have been incorporated.Improved device support in some existing drivers.Some new device drivers have been added.Some minor userland fixes have been applied.The stability of the sparc64 port has been greatly enhanced.
Can you give us a short introduction to yourself and your role as a NetBSD-Core member?
I've been a NetBSD developer for seven years, and a member of core for nearly four years. As a core member, I help set the technical direction of the project and arbitrate technical disputes.
As we can read on your home page, you're working on various tools to make it easier to cross-build NetBSD releases from other platforms and architectures as unprivileged users. Can you share some plans with us?
The "base" NetBSD product (i.e, NetBSD's /usr/src) has been able to be cross-built since before NetBSD 1.6 was released. The infrastructure exists to build an entire NetBSD base release on a foreign system (including older NetBSD releases) as a non-root user.
It is now possible to cross-build XFree86 4.x on NetBSD-current using the build.sh (1) framework, taking advantage of such features as cross-compilation, read-only source trees, and unprivileged builds.
Various platforms have been converted to this framework, and all platforms should be able to build everything other than the X servers. Some platforms have working support for the X servers as well, including i386, macppc, sparc, hpcmips, vax, and x68k.
There is also a work-in-progress to cross-build pkgsrc (third-party packages) using hardware simulators/emulators. The work in this area looks very promising.
How is the relationship between the NetBSD programmers and the OpenBSD/FreeBSD/Darwin ones? Do you share code, opinions, chat regularly? Or are all these BSD projects completely independent of each other?
Various developer liaise at the individual level. There is code sharing of different portions of the code (e.g, nsswitch and rc.d from NetBSD to FreeBSD, the kqueue code from FreeBSD to NetBSD, etc.), and we generally encourage cooperation to avoid unnecessary "code skew" when the software is migrated around.
There are some open mailing lists (bsd-api-discuss, bsd-api-announce) that were set up by Perry Metzger, a NetBSD developer, for the purpose of discussing APIs and other issues that could be shared between the various *BSD projects.
How about capturing new developers and users?
Generally NetBSD hasn't run the same level of marketing campaigns that other projects have to gain new users; we develop a good product that speaks for itself, and we still gain a lot of new users. We recruit new developers from our user community; usually they're users who've shown their level of expertise by submitting problem reports with working bug fixes or new features, or new or updated
Do you have any advice for would-be NetBSD developers?
Show the rest of the developers that you have something worthwhile to contribute to NetBSD, and convince someone to be your sponsor.
Is it true that -current will be called 2.0 and not 1.7?
Correct. The next major release of NetBSD will be NetBSD 2.0.
Is there any timeline for the release of 2.0?
We had planned to branch 2.0 early this year. I would conservatively say that we'll have the release shipped by the middle of the year, although I would hope that it occurs before then.
What goodies will 2.0 bring us?
SMP on more platforms, including i386, macppc, sparc, alpha, and vax.
Kernel assisted threads ("schedular activations").
Fully dynamically linked userland.
Does choosing a major number release mean that you'll include some deep changes, like FreeBSD 4.x and 5.x?
Not necessarily; it's just a minor change of direction with our numbering. For a *long* time we have planned to call the release of NetBSD that gave us reasonable SMP 2.0.
Will NetBSD go in the same direction of FreeBSD 5.x introducing MAC deep security capabilities or it will follow an usability approach like OpenBSD?
No idea at this time. We may pick up the MAC stuff from FreeBSD if the demand is there.
Have you ever planned to use only systrace instead of suid flags?
Not specifically; I haven't given the issue that much thought. I suspect that there will always be a need for some level of suid programs, although systrace could probably be used instead of suid for applications that only need to do a small number of privileged operations (e.g, "bind to port 80").
PF and IPF -- is there a religion war?
Not really. I prefer IPF myself, but that's probably because I know Darren Reed personally so I can ask him IPF questions in person :-)
IPF is portable across many platforms, including various commercial Unix variants, and that is a benefit for heterogenous sites with those systems.
NetBSD's goal is to port the OS to as many platforms as it can. Which missing platforms are most important?
It would be good to get an Itanium port, as that is probably the most well-known modern CPU that we don't run on at this time.
Binary compatibility is strategic for a niche OS. It seems that writing compatibility would be a good way to discover what features you don't yet support. Of course, NetBSD is a mature OS, but have you found any improvements that needed to be made?
There are always things to be improved :) We have over 3,000 problem reports currently open in our bug tracking system, and people have a bunch of personal projects that they'd like to work on as well.
How many people are there on the release engineering team, and what are their duties?
The release engineering team for NetBSD 1.6 was primarily me, with a bit of help from a couple of other people. After the release of 1.6, a few more developers were able to contribute time to the maintenance of the NetBSD 1.6 CVS branch, and managed patch updates and release engineering for the maintenance releases NetBSD 1.6.1 and 1.6.2. There are about six active members of the NetBSD 1.6 release engineering team.
What are the major jobs during the release engineering cycle?
Branch the CVS repository. Manage pullup requests (of fixes or enhancements) submitted by other developers. Ensure that the nightly autobuilds are completing successfully. Coordinate testing of the release betas. Prepare and populate the "official" release directory on ftp.netbsd.org. Create and publish .ISO images of the release. Coordinate building of the X11 sets between the various platforms.
With the many different machines supported by NetBSD, how was the binary distribution available on the FTP server created? Did you have all machines available and do all the builds yourself?
Prior to NetBSD 1.6 we had to coordinate between many different developers to get builds of the release made. This used to take a reasonable amount of time, as some of the slower platforms can take a significant amount of time to build a release (in the order of days).
For NetBSD 1.6, we cross-built 37 platforms on a dual processor AMD MP2000+ machine (approximately 27 hours), and the two 64-bit platforms (alpha and sparc64) on an Alpha CS20 (in less than 4 hours). We used this cross-build infrastructure throughout the entire release engineering phase of NetBSD 1.6, and this allowed us to have new test betas available on a near daily basis. We still had to coordinate the X set build with people who had the actual hardware to build X natively, but that was not as difficult as coordinating an entire release build that way.
We expect to be able to build more platforms for NetBSD 2.0, and hopefully we'll be able to cross-build X11 as well. That's a project that I'm working on in my spare time.
Do you plan to include any type of memory protection in future releases (OpenBSD W^X, Linux PaX, ...)?
We got non-executable mapping support in August 2003 for some NetBSD platforms.
Chuck Silvers did the work, based on the code in OpenBSD. NetBSD architectures that support it include alpha, i386, sh5, powerpc, sparc, and sparc64. Architectures that could support it that currently don't are hppa and x86_64.
There's some information at http://www.netbsd.org/Changes/#nonexec-stack-2003-08-26, which links to
The number of wireless networks is growing, but it seems that some recent standards like 802.11g will introduce a problem for open source device drivers. What type of future can we expect for *BSD?
NetBSD's supports 802.11a/g via Sam Leffler's ath driver, which is implemented as a source layer to a binary HAL that controls specific elements of the device.
NetBSD is pragmatic and understands that there are issues for hardware vendors like Atheros, such as FCC compliance when using software radios, so we'd rather work with the vendors than against them.
Do you think SCO lawyers will sue NetBSD or other BSD projects? If that happened would the open source community help them?
I have no idea what SCO's intentions are. I have no doubt that if NetBSD were sued by SCO that NetBSD would receive support from various organisations and companies.
Any plan to develop something like user level Linux or virtualization extensions for the FreeBSD kernel?
I'm unaware of any, although that doesn't preclude anyone from working on them or porting FreeBSD's work.
At the beginning of the year a NetBSD logo contest was launched. Why a new logo? Are you looking for a mascot too?
The RFL announcement lists the problems we had with our current front page image, including that there were some concerns about the negative religious ramifications (of the daemon). FreeBSD effectively "owns" the daemon, in that when most people see the daemon they think of "FreeBSD" not "*BSD" or "NetBSD." We want our own identity.
Some people seem to confuse the concept of a "logo" with a "mascot." NetBSD wants a logo that uniquely identifies us.
Can you talk about the role of NetBSD Foundation and present some events where it made the difference? Other free Oses and projects are not so well organized.
The NetBSD Foundation is the legal entity that owns the intellectual property and trademarks associated with NetBSD and any assets and equipment that have been donated to NetBSD. The NetBSD Foundation has obtained 501(c)3 non-profit status with respect to U.S. taxation, so companies and individuals that donate to the NetBSD Foundation are able to claim their donations as a tax deduction. The Foundation allows the NetBSD project to concentrate on implementing the technical issues of the NetBSD operating system and associated products (including pkgsrc) and takes the administrative burden off the NetBSD project.
Federico Biancuzzi promotes *BSD systems in Italy as the director of the BSD Zone of an important magazine. He was the coordinator of the first BSDCon Italy during 2003.