Original audio available at bsdtalk.blogspot.com. This document is available in other formats at http://derek.trideja.com/bsdtalk/.
BSDTalk: Hello and welcome to BSDTalk #64. It's Monday, September 11, 2006. I just have an interview for you today but before that, I just wanted to take a minute to thank everyone that's been helping me out with this podcast. Even though I'm the only voice you hear during these introductions, there are a lot of people that are contributing, either equipment, or bandwidth, or doing transcripts, or just sending suggestions and words of encouragement, so I just want to thank everyone for that.
All right, onto the interview. Today on BSDTalk, we're speaking with Jason Thorpe, and I want to welcome you to the podcast.
JT: Great, thanks for having me.
BSDTalk: So just to get started, maybe you could describe a little bit about what you and how it relates to the BSDs.
JT: Well, currently, I work at Apple Computer. I'm an engineering manager here for a filesystem product called Xsan, and while that's not directly related to, really, what I do with the BSDs, I actually have been a NetBSD developer for quite a long time—since, uh, since back when I was in university, back in uhm... oh, I don't know, I guess I started using it back in '93...
BSDTalk: And what attracted you to the BSDs or NetBSD in particular?
JT: I went to Oregon State University and we were actually quite near the, uh, what was at the time, the largest Hewlett-Packard campus in the world. And we had a pretty big supply of the old 9300 series computers, and we ran kind of a mix of operating systems on them. We had some running versions of HP-UX, various versions of HP-UX, and we also had a few that were running a version of BSD from the University of Utah called HP-BSD. It was based on 4.3 and had some extensions like NFS and NIS that were licensed from Sun. And so that's kind of how I got started using it. I mean, that's what got me really interested in working on BSD.
BSDTalk: And from there you actually—from what I read on your home page—moved onto some jobs that paid you to work on BSD.
JT: Yeah, absolutely. So that actually started when I was at the university. One of the things that we did is we actually had an HP 300 that was serving a large NeXT software archive, and one of the things that I did as part of my job, I worked for the CS department there in addition to attending university there... was I... basically did some work on the ccd driver, which is kind of a RAID implementation, simple RAID implementation that's in NetBSD, to get it working on NetBSD on the HP 300 way back when it was something that was part of 4.4BSD, but it was really experimental and didn't work so well on NetBSD and did some work to get that working in NetBSD.
So that was, I think, probably my first, sort of major paid BSD kernel work. But yeah, after I was done with school, I actually got a job at the Numerical Aerospace Simulation Facility that's located in Mountain View, California, on the NASA AMES research center campus, and I actually went to work there doing NetBSD work.
We had a large hierarchical storage management system that we were developing that had been through several generations. It had originally, well, at the time when I was there, it was running on a Convex system, a Convex 3820, and we needed to move it to kind of a more modern platform, and the platform that we picked was the DEC Alpha, AlphaServer 8200, 8400, which was kind of DEC's big iron at the time. And we had a policy of having the source code for everything that we ran there in that computer room, so obviously we wanted to pick something that would be... make it easy to have the source code. We could have licensed Digital Unix, but we actually chose to use an open platform because we were interested in sharing some of the filesystem work we had done. So we actually did a lot of work to port NetBSD to the AlphaServer 8400.
The original groundwork had been laid by Chris Demetriou at Carnegie-Mellon when he did the original NetBSD Alpha port, but did a lot of the work to actually port it to the big AlphaServer platforms. There was quite a big filesystem and a networking project that came out of that. We touched a lot of pieces of the—really the network stack, the VM system, device drivers, the SCSI infrastructure, lots of, lots of different stuff. And the way the system worked is that we had a large tape library that was connected to the system, and the filesystem would transparently migrate data from the disk to the tape and back. Uhm, the sort of catchphrase for that now is "information life-cycle management". We called it HSM for Hierarchical Storage Management.
And then we did a lot of work on the TCP/IP stack also to get that data quickly over to the Cray Supercomputers over a networking infrastructure called HIPPY which isn't really in use anymore, but it was a big 800 megabit-per-second parallel network with very thick copper cables, so that was the work I did there. It was pretty interesting.
BSDTalk: And after there, you moved onto, I guess, a fairly well-known BSD company.
JT: Well, yeah, so, actually in between those, a bunch of us decided to leave NASA and we went to a company called Zembu Labs which—I don't think is the company you're referring to—but at Zembu we did a lot of NetBSD work as well. We actually had some network infrastructure management appliances that were based on NetBSD. Unfortunately, Zembu imploded in the dotcom implosion, and when that happened, I moved on to Wasabi Systems which, I think, is what you were referring to when you referred to the well-known BSD company.
BSDTalk: Were you working on their embedded stuff there?
JT: Yeah, so, when I first started at Wasabi, it was still primarily a services company, and was doing some work on, y'know, various embedded projects. And at the time, there was some interest from Intel, actually, to do some iSCSI-related work on some new XScale-based I/O processors. And we were contracted to do a port to one of their eval boards for one of their new I/O processors, and I was heavily involved in that. I did the original port to that I/O processor and we kind of continued that relationship, did more ports to more of their IOPs and more of their eval boards. And that was really the birth of the Wasabi iSCSI product that they now sell as StorageBuilder. They initially started out, you know, doing this on small embedded systems and then, you know, grew it to run on, sort of IA-based appliances.
BSDTalk: I kind of assume that you're most known for your work on the Alpha port.
JT: Yeah, I definitely did a lot of very publicly-visible [laughs] work on the Alpha, definitely.
BSDTalk: But was your work on the Alpha because the place you were working at was going in that direction, or did you also have a personal preference for the Alpha platform.
JT: Right, well, I was never really a big fan of the Intel architecture, so Alpha, I liked it just from, you know, in one sense I liked it because it wasn't Intel. I was definitely a RISC fan [laughs], and in a lot of ways, the Alpha is one of those architectures that's very clean, it's really easy to work with. Some parts of the architecture can be complicated but there, it's certainly a lot easier to program on the bare metal than, you know, sort of an equivalent IA-based system. But yeah, I think the initial push for me to look at Alpha was that that's where we were going as an organization, as what we were looking at. But once I started working with it, I definitely, I mean, I kind of fell in love with it, and... I like refer to Alpha as 'MIPS done right'. You know, it was heavily-influenced by the MIPS design and it's very obvious when you sit down and look at the way the assembly language for each of those processors works.
But there are some things about the Alpha that were, in my opinion, a lot cleaner than the way it was done on MIPS, especially surrounding the part of the Alpha architecture called PAL code. And what PAL code does is it abstracts the low-level per-CPU implementation bits like, you know, TLB management and interrupt handling and stuff like that, kind of away from the operating system... gives you kind of a more abstract view of it, and also allows you to layer certain types of semantics that an operating system might need to support that operating system better. So, the Alpha, for example, had three flavours of PAL code: one for OpenVMS, one for Unix, and one for Windows NT. And all of them provided kind of a slightly different set of semantics, like the VMS PAL code, for example, provided a lot of the inner-locked queue manipulation facilities that previously existed in the VAX instruction set, but were not native instructions on the Alpha. Well, those were available as PAL code routines on the Alpha, which made it a lot easier to port that operating system to that platform.
BSDTalk: How open was Digital Equipment Corporation or HP with their hardware specifications for the Alpha platform—not only the chip, but the associated chips that come on the actual machine?
JT: Sure, well actually, DEC was very good at this. You know, you could go to the DEC website and download the chip documentation for the core logic chipset parts, and they were actually fairly interested in supporting open source on the Alpha platform. I mean, there were people inside DEC who were big Linux fans, and so there was, if not paper documentation available, there was certainly example code available written by DEC, and you know, in the form of Linux. That said, there was a lot of paper documentation available. We did all of the AlphaServer 8200 bringup using paper documentation, and that we were able to get from Digital without any encumbrances. In fact, for a very long time—I think this might still exist—at the netbsd.org website, have a pretty good library of DEC documentation in the form of, you know, PDF or PostScript files for the various chips that are in Alpha workstations.
One of the nice things about the Alpha platform is that, especially the PCI Alpha systems, the ones that came later... they were very much like PCs in the sense that, you know, they used PCI and they had a lot of the same types of support chips that PCs had, so there wasn't a whole lot of, like, secret sauce that you had to know, right? There were things like how to talk to the PCI controller or how to control the PCI memory mapper and things like that that you had to deal with, but that documentation was all public. And the interface between the processor and that core logic chipset for, like, interrupt handling and stuff like that was all abstracted away by PAL code, so there wasn't a whole lot of secret stuff that you had to know. So, it was really nice in that sense, and you know, there were a couple cases where we actually got a new Alpha system... could be brought up within just a few days because the documentation so good. And Chris Demetriou did such a great job of the original port, and so it was really modular and really easy to drop in new stuff once you got the documentation and the hardware.
BSDTalk: Speaking of an Alpha machine having a lot of things in common with a PC, my actual first experience with an Alpha was basically as a PC, back in the early days of the Lightwave animation package from Newtek...
JT: Mmhmm...
BSDTalk: ...and a lot of that stuff was being done on Windows NT, and then it went away, but... [laughs]
JT: Yeah, a Windows NT Alpha system, it was not too different from using Windows NT on a PC, except it was a hell of a lot faster. [laughs]
BSDTalk: I guess some of the historical benchmark tests they had for the Alphas, the throughput was pretty good on those things.
JT: Yeah, the Alpha was—it was interesting their kind of approach. They started out, kind of with, going with brute force clock speed, you know, method of getting performance in their first Alpha implementations, and they were just the fastest chips around because of that when they first came out, like the EV4 processors and the first Alpha workstations and servers. And then they started to add a lot more interesting stuff in the later implementations like the EV5 and EV6, corrected some unfortunate things that were missing in the earlier implementations, like the lack of byte load and store instructions. They added those in the EV56 and the PCA56, I believe they added those.
They definitely had a good architecture to start with, something that was clean and simple, and that allowed them to add more interesting and modern processor features in the later implementations of the architecture. And honestly, I really miss it, actually. It was a pleasure to work with those machines and it's been painful to me to think about getting rid of my old Alpha systems I don't really use anymore. They kind of consume a lot of heat for the amount of work that you can do with them anymore these days, and the last time I moved, I didn't, I haven't unboxed them yet. [laughs] But yeah, I can't really bring myself to get rid of them just because they have such fun memories of doing system programming on them.
BSDTalk: I'm sure there's a lot of people who would love to take 'em off your hands.
JT: Yeah! [laughs]
BSDTalk: So at this point, would you consider the Alpha port of NetBSD to be on par feature-wise with the other top architectures with NetBSD.
JT: Well... in... most respects, yes. Actually, the Alpha was one of the first platforms to get some multiprocessor support. I think it was actually the first one to really run well with multiprocessor support. A person named Bill Sommerfeld and I did a lot of work on that, and Bill was working primarily on Intel, and I was working primarily on Alpha. We kind of had a little friendly competition going, who could get it to run multiuser first. So that, a lot of that initial work was done... in some ways, the Alpha port did lag behind in support for graphics, especially on the PCI systems, and that was largely due to the architecture of the XFree86 X server package and the assumptions it made about how it was able to access the actual device, the graphics card. It made a lot of assumptions related to how the address space was laid out.
On the Alpha, because of the lack of byte load and store instructions on the earlier implementations, devices can't pack byte-wide registers right next to each other, so what happens is the Alpha address space for PCI is sparse. So every byte is separated by another seven bytes of non-responding space, and so software has to compensate for that, and in NetBSD we have this bus space API that kind of handles that for device drivers, but in user space, which is where the X server runs, we didn't have anything like that. And looking back on it, I probably, as portmaster, should have addressed this a little sooner and said, "Yeah, XFree86 is really out of my control, I can't really make their decisions for them, and if they want to program in this way, I should figure out a way to make it work," which is eventually what happened. But for a long time, the Alpha port lagged behind in graphics support for the PCI systems for that very reason.
It was a little sad that the old TURBOchannel systems were better supported as workstations than the modern, faster ones were. But eventually that got rectified, and pretty much, the Alpha port has pretty good feature parity with everything else. The bus DMA and bus space APIs in the NetBSD kernel mean that the device drivers are generally just going to work, so assuming that driver writers use those APIs properly, all the devices are generally going to work on the Alpha platform. And, you know, things like the installer, work just as well as they do on other platforms. I would say at this point, it has feature parity.
BSDTalk: And when you're working with NetBSD, are you still working primarily on the Alpha platform or other platforms?
JT: Unfortunately, I'm not. As I say, I still have my Alphas but I haven't powered them on for a while, I'm sad to say. I do most of my NetBSD work these days actually in emulators or virtual machines. I—just for space constraints—don't have quite the collection of hardware that I used to have at my house, so I have a small little farm of Macs that I run at home, and on my Intel-based MacBook Pro, I run the Parallels virtual machine, and I'm able to run NetBSD inside of that. And I actually do run a NetBSD-based server for —my wife's a photographer and her business uses NetBSD as IT infrastructure, so we actually do have some NetBSD in production for her company. I still have some NetBSD machines that are just waiting for me to finish running Ethernet down to the basement to them and be able to power up them and actually run my NetBSD-based server at home again. Yeah, I haven't done a lot of work on the Alpha for a while, it pains me to say.
BSDTalk: Are you running it on any toasters?
JT: Don't have any toasters, sadly, to run NetBSD. I think my wife would get upset if I had one of those in the kitchen. But I actually did have a fairly esoteric collection of weird little embedded stuff that I'd collected over the years, including a little device called the SurfQ(?) which I never really got around to porting NetBSD to, but it was about a 2.5x2.5x2.5 cube that had a little StrongARM processor in it, and was perfectly capable of running NetBSD. There was a Linux port to it; never really got around to getting NetBSD to run on it, though.
BSDTalk: I've got two old Silicon Graphics workstations that I figure I'll probably put NetBSD on eventually...
JT: Absolutely...
BSDTalk: With SGI's announcement that Irix and MIPS are going away, I kind of feel bad about uninstalling Irix...
JT: Well, luckily, MIPS isn't going away in general. It's... I think it's either the number one or number two embedded processor—actually, I think ARM is number one, but MIPS is probably the number two processor at this point. MIPS as an architecture, thankfully, is not going to die.
BSDTalk: You did mention a MacBook Pro, and I know a lot of the open source operating systems have been working on getting things running natively on it. What used to be a BIOS is now a little bit different—are you hoping to devote some time to getting a native port?
JT: What's kind of nifty about the new Intel-based Macs, actually, is that they're actually capable of running vanilla PC operating systems pretty easily. I do know that things like Linux and Solaris will run on the new Mac Pro systems, the new desktops, with the Apple Boot Camp program, and what Boot Camp does, is it provides a sort of BIOS shim between the operating system and the EFI firmware that's running natively on the Mac. It actually allows the systems to boot and run and they don't even know the difference, so I'm hopeful that NetBSD will just work in that sense. I haven't actually had the opportunity to try it myself—you know, just a little too busy with other stuff, plus I run it within the Parallels virtual machine which I find a lot more convenient because I don't have to reboot the computer, and it's still fast for everything I want to do.
But, yeah, I believe a couple of people have tried it. I think there are a few things to fix. You do definitely have to use ACPI for system configuration on these new machines, so there are a few nits here and there that need to be addressed, but I don't expect that there's going to be a whole lot of trouble. I expect someone will get around to it. If I do, great, if not, I know someone else will.
BSDTalk: And besides trying to get it all working on new hardware, are there any new pieces of software that you're working on or thinking about adding to NetBSD?
JT: Yeah, I have a couple of projects going right now. The first one is actually something that I recently checked into the NetBSD source tree that I call proplib. What it is, it's a replacement for the old properties API that we had in the NetBSD kernel. The main difference that the new proplib API has is that you can have properties as a child of another property, right—in fact, I actually modeled it primarily after the property list APIs that are in Mac OS X, in the CoreFoundation framework. Basically what it allows you to do is create string objects or number objects or boolean objects, and then you can put those objects into containers, and that container might be just a plain array, which is just an ordered set of items. And then the other collection is called a dictionary, which is basically an associative array, right. You give it a key and out comes a value, and vice versa if you want to set a value.
One of the cool things about proplib is that there's this externalized representation, so there's a copy of the library for user space and a copy for the kernel. In the kernel, for example, you can generate a list of properties for something and then, if you want to send those to user space, you translate into them the external representation, which is actually an XML text, and then you copy it across the protection boundary, and then in user space, you can re-convert that to the internal form. So you can pass, basically, arbitrary data between user space and the kernel without having to worry about versioning, data structuring, it's completely extensible. The only thing you really have to watch out for is if you remove a key from the dictionary. Say you have one version of a dictionary that has key called 'foo', well, if user space code on the other end expects 'foo' to be there and you remove it at some point, then user space code might break. But that generally doesn't happen, and the thing you have to look out for is changing the semantics of how the keys work.
But other than that, it basically allows you to add arbitrary properties to things and be able to pass them back and forth in what's an ABI-stable way. We're actually looking at making use of this in a lot of different places in the kernel right now. The new Bluetooth stack NetBSD has makes use of it for configuring devices and keeping some persistent configuration information for them, because you can save these externalized forms just as a file as well, and then read them in later, and build up your internal in-memory data structure out of a file. We're looking at using it for describing the layout of partition maps on disks and how to describe the properties of a disk device, so we can decouple ourselves from some legacy data structures that have some limitations we'd like to get away from.
Eventually we'll convert a lot of things that have traditionally used flat binary representations of things like ioctls for configuring network interfaces and whatnot. Eventually we can convert those to property lists also, so we can more easily adapt to new types of hardware that might have completely different kinds of properties than we used to handle back with just the old legacy code that was not very extensible. And it eliminates us having to version these interfaces all the time because it's kind of self-adapting, self-versioning.
So that's the first major project I have right now, and that code is actually available and it's going to be in the NetBSD 4.0 release, and it's in use by a few things already, and then more and more things are adapting it as we speak. I've got conversations going with three or four other NetBSD developers asking for advice on how to use this in their code, so that's encouraging.
Then the other main project I have going on right now is—kind of a background: a few years ago, I sat down and wrote a clone of the Solaris locking implementation, so I basically sat down with a Solaris Internals book, read about how their mutex and RW locks worked, and sat down and wrote a clone implementation of those, and the goal of that is to basically improve the locking facilities we have inside the NetBSD kernel so we can improve our multiprocessor support.
One of the big barriers we have to improving multiprocessor support in NetBSD right now is the fact that the locking API we have is just not so good. It's slow, it's kind of inflexible, it consumes a lot of memory for the actual lock objects itself, and it requires you to also do the interrupt priority manipulation manually along with the locks themselves. And that's problematic when you're working in an MP environment. When you're working in an MP environment, you really want to get away from thinking about blocking interrupts, protecting code as opposed to protecting data structures.
The new locking API that—the person who's really driving that now is a fellow named Andy Doran and he's basically taken this code that I wrote some years ago and is kind of updating it, and cleaning up some of the nits, and getting ready to check it in to the NetBSD source tree, and I've been involved in helping him review the code and answering some questions and getting it polished it. We're having kind of a nice thread on our tech-current mailing list about how this new locking stuff should work, so I'm kind of involved with that. Not as much as I was in the past, but I'm definitely involved and glad that someone else has really picked it up and running with it.
BSDTalk: NetBSD, from what I've read, strives to support all their architectures using a single codebase, and a lot of these optimizations that you're looking to do either with locking and other stuff, could perhaps be more efficient if they took advantage of architecture-, processor-specific features. And do you feel there's a benefit, one way or the other, of shooting for architecture-specific features?
JT: Well, in the case of the locking API that I just mentioned, actually, it is a generic API, but it's also able to take advantage of processor-specific optimizations. Like I say, we've modeled the design very much after Solaris, and Sun did a very, very, very good job of really thinking through how this should work and how you can provide a generic API that also takes advantage of machine-specific optimizations. And we've been able to do that. Now, that said, there is some discussion these days in NetBSD about what we should do about the really old platforms, some of which may not be as well-supported as others, partially due to just the processor being so antiquated, or maybe an inactive port maintainer not really keeping the port up to snuff.
So, in those cases, I feel that eventually what will go in is to probably come up with a tiering system that says that, you know, some platforms are more important than others, and if advancing one platform means that an older platform might slow down a little bit, then that's kind of a price we're willing to pay. I don't think that we have to fork the codebase. I don't think that we have to shed ports completely. In the history of NetBSD we've only ever deleted one port, and that was because the only two machines that existed were destroyed by the guy [laughs] who designed and built them. So we have a pretty good record of keeping platforms around, but that said, eventually if it becomes too hard to maintain something, then we may have to make the hard decision to say, "Sorry, this is not supported anymore."
Now, I'm not really in the project leadership anymore, so obviously it's not my decision to make, but we have, there's a good group of guys in the core team of NetBSD that is set up to make those decisions. We trust that they'll make the right ones.
BSDTalk: And changing topics a little bit here, how much does the licensing of BSD affect you, or how important is it to you?
JT: It's very important to me, I mean, it's no longer important to be professional in the sense that I'm not directly working with NetBSD at my job anymore, but in terms of the way I believe software should be distributed, I feel that the BSD license actually provides developers with more freedom than the GPL does, because it allows them to do more things with it than the GPL allows them to do. So, in that sense, I believe in the BSD license from that perspective. Now, back when I was working with it professionally in commercial enterprises, I thought the BSD license was great, because it meant that I could extend software in ways that maybe had some secret sauce in it, and it meant that I didn't have to give that code away, which was important... some of the projects that I worked on at various companies that I did NetBSD work in.
When I was doing that at NASA, all that code was open source, so we contributed everything back to the NetBSD community, but you know, a lot of the work I did at Zembu and a lot of the work I did at Wasabi was not contributed back to NetBSD for a couple of reasons. Some of the things that we did to the operating system was not necessarily appropriate to be contributed back because we were doing it for specific applications. But at the same time, especially at Wasabi, we had customer requirements in certain cases that prevented us from being able to share machine-specific code because maybe it was some very secret, proprietary hardware. But if we had been using Linux, for example, anytime someone had gotten a hold of a binary for that, they would have had to disclose the source code for that, and that might have meant that instead of using an open source system, that hardware vendor might have gone and used VxWorks or something like that.
So, I think overall, it was good for open source to have an option for hardware developers that did not require them to disclose source code, because it meant that they were indirectly supporting open source by hiring, you know, Wasabi, to do work for that platform. So in that sense, I think that the commercial-friendly aspects of the BSD license were beneficial for everybody.
BSDTalk: On towards maybe career and advice to programmers, you spent a lot of time working for commercial companies, being paid to code...
JT: Uhuh...
BSDTalk: ...and at the same time contributing to a public project.
JT: That's right.
BSDTalk: I assume—because I'm not in the programming field myself—that you have to be careful to kind of mark off when you're programming for NetBSD and when you're programming for your employer.
JT: Yes, you do. And, unfortunately, that sometimes varies from state to state.
BSDTalk: You know, what I'm kind of imagining, you're currently working for a commercial company and at the same time, you're developing things for them and you're also developing things for NetBSD, and how do you go about keeping track of which ideas you came up with when you were on the job and when you were eating dinner?
JT: That's a tricky one. Thankfully, some of the laws in the state of California help me out with that. California's employment laws make it so that things that you came up with at dinner are not work for hire for your company, which is good. So, in some ways, like I say, that can vary from state to state, and I'm lucky to be in a state that sees the value of innovating at your dinner table. So, in that sense, I'm okay. One of the things I would advise open source advocates or open source enthusiasts who are getting out of school, getting ready to go to their first jobs is, one, investigate the laws in the state that you live in. Find out what protections and rights you have. Also, bring it up with your prospective and employers and discuss it. A lot of companies are not necessarily going to object to you having open source enthusiasms on the side. So, I think that the most important thing is to, one, be educated about what your rights are and what your protections are. And then, two, it never hurts to talk things out with a prospective employer, and you know, if a prospective employer has a problem with it, then if you feel strongly enough about it, it's good to know up front before you have to make a decision about whether or not you want to work for them.
That's the main advice I would have for people who want to continue their open source work and maybe have concerns about whether or not that's possible with their employment arrangements. That said, there are a lot of open source developers out there and a great many of them work at commercial software vendors, so obviously this problem is solvable because it's out there and solved in the real world and in practice.
BSDTalk: All right, and then moving onto some of your personal use of NetBSD, some of the questions I like to ask are, do you use it as a workstation, what's your environment look like—whether you use a graphical environment, editor, favourite window manager and that wonderful stuff.
JT: I actually, my main desktop machine is a Mac, so I don't really use NetBSD as a desktop machine. I do—I did at one time. I carried around an IBM ThinkPad that ran NetBSD. I just used the TWM window manager. I kind of like the minimalist approach if I'm running X, although, like I said, I haven't run the X window system for a great many years now. But in terms of how I use it, I still am very much a command-line oriented guy. Even when I'm programming in a Mac environment, I use vi [laughs] even though we have this big wonderful integrated development environment called Xcode on the Mac. I actually use vi for a great many things that I work on at my job.
But yeah, I know when I'm using NetBSD, primarily I'm use NetBSD these days for developing NetBSD. Like I say, I do still use it as a server platform for my wife's company, and that works great, and it's a server, so I'm all command line there. But when I'm using NetBSD on my Mac inside Parallels, I'm using just completely terminal-oriented stuff. No GUI. I've got my Mac for that. [laughs] And that's not because I don't think it works well on NetBSD, it's just that I don't like any of the X window-based user environments at all. Like, I'm not a big fan of GNOME or KDE. I actually find X to be really clunky, and just the inconsistency among apps makes me grit my teeth a little bit. I just like the Mac a lot better as a desktop for that reason.
BSDTalk: And what about a favourite programming language?
JT: Oh, C. [laughs] Although I am, I am a fan of Objective-C, but definitely I code a lot in C.
BSDTalk: Yeah, I guess, you know, Apple Computer and NeXT were Objective-C...
JT: Yeah, exactly.
BSDTalk: All right, well, are there any other topics that you want to talk about today?
JT: I guess maybe just in closing, I'd like to encourage people to get involved with NetBSD. There are some really interesting projects that can provide a great opportunity, especially for younger developers, to gain a lot of experience in doing interesting OS work—bringing a system from a legacy Unix model to a new, more modern multiprocessor-type model. There's some momentum, you know, gaining steam again in that regard in NetBSD, and people should try to get involved.
It's a great opportunity to learn and put that stuff on your résumé when it comes time to hunt for a job. Because as someone who, I'm a manager here at Apple, and someone who interviews people, when I see cool OS work or something like that on a résumé, it impresses me because I know what it's like to work on that type of stuff. And no, I'm not the only manager that hires people in the world that does that, so I definitely encourage people to get involved, volunteer to do challenging and interesting work. It's a great way to grow professionally in your spare time.
BSDTalk: All right, well I want to thank you very much for speaking with me today.
JT: Well, thanks very much for having me. I appreciate the opportunity to talk with you.
BSDTalk: All right, thank you.
JT: All right, take care now.
BSDTalk: If you'd like to leave comments on the website or reach the show archives, you can find them at bsdtalk.blogspot.com, or if you'd like to send me an e-mail, you can reach me at bitgeist@yahoo.com. Thank you for listening. This has been BSDTalk number 64.
[transcribed 11-Sep-2006 by Derek Warren - derek@trideja.com - http://derek.trideja.com/]