Will: Hello and welcome to BSDTalk #46. It’s Friday, May 19th, 2006. We just have an interview, so we’ll go straight to it.
Well today on BSDTalk we’re speaking with David Gwynne, and he is an OpenBSD developer. I want to thank you for coming on to the podcast. This year you were at BSDCan. I unfortunately couldn’t make it. So, I was wondering first if you could answer some general questions about BSDCan: what was the experience like for you, how long were you there, the general attendance, talks, social events, generally how you thought it went…
David Gwynne: To be honest, my biggest impression of BSDCan was coming through US customs on the way. They held me up and were a bit curious about all the equipment I had in my bag there. Also, the flight was pretty long. Coming from Australia, it was like a 12 hour flight from Tokyo and I’d had about…no sleep by the time I arrived in Canada. But yeah, it was fine. I haven’t really been to many conferences [undecipherable] so I’m not sure how I’m supposed to compare it to other ones.
W: Did you go to a lot of the social events?
DG: One or two of them. I mostly hung out with the other OpenBSD developers that were there, and we tend to do our own thing sometimes. But generally we went to the social events.
W: How would you compare it to the hackathons?
DG: Extremely different, because at the hackathons it’s more about small discussions where you’re trying to solve a certain problem and you just sit and write code most of the time while BSDCan was very much a passive experience I found. Apart from presenting, it was just sit and listen basically. In between talks it was good to be able to bounce ideas off people and such, but, yeah, it’s a world of difference.
Linus does not code a lot anymore these days. Talking (mostly to developers) is his day job now. So let him talk all he wants.
Quoting Linux himself: "Well today what I do mostly is actually communication. I started out as the main developer but these days what I do is act as the central point for other people who do a lot of development and I gather it all together and basically communicate with people what needs to be done and so on." source of quote
Not sure Linus would be that relevant to BSD, as he really doesn't have much to do with it. The only thing that might be interesting to me is why he didn't consider using 386BSD back in 1991. Was it due to the AT&T lawsuit or were there other reasons?
DG: The talk I did was on sensors and bio in OpenBSD. Sensors are basically just anything environmental about your system and the levels of redundancies that your hardware has. Like if you have three power supplies and one of them goes off line, the sensors framework is there to report it. And bio is about managing your RAID sets. It’s a very basic level of management, but it’s at least some management and doesn’t rely on any vendor tools to do it.
W: In your opinion, how mature do you think these are?
DG: The sensors framework has been there since 3.4 or 3.5 and we inherited it via NetBSD. I think grange did the work to bring it in. But, it’s only been in the last six or eight months that we’ve actually really tried to write drivers for it and bring it up to speed. To be honest, it is a bit raw still. It needs a lot of work, and we’re looking at that.
Bio is totally homegrown. It’s only been around sort of since the last hackathon, and it’s remarkably useable. Yeah, it just works.
But yeah, sensors needs some work, especially in the userland part. The sensors daemon needs a rewrite basically.
W: Yeah, one of the issues I’ve had with sensors is it does a wonderful job of listing fans and other things, but I’m not sure which fan is which in the sense of mapping what you get out of sysctl with the actual devices on the board. But I guess that’s a problem no matter what.
DG: It depends on which hardware you have in your system. On a lot of the desktops and lower end server stuff, they have these very standard chips that can be hooked up in a variety of ways. So people will stick in this really, really dumb chip and hook it up to temperature sensors, and all we know about that chip is that it has four fans on it. So we enumerate them “fan one, “two”, “three”, and “four”.
But if you go up to the higher end of the spectrum of hardware, into the SCSI realm, you can actually query the hardware for the names of devices. And that’s what we present in the sysctl tree. So, if you look at esm or ipmi for example, it’ll actually say “baseboard fan 1” or “power supply 2” or something like that.
We do our best, but at the low end, we can’t tell what it’s physically plugged into so we just say what it is hooked up to, not where it is.
10 comments:
Good work man :) \/
You can soon release a CD
thanks
momchil bojinov
Great interview! Someone be his sugar mummy so we get more great code out of him. ;)
Thanks for all the Interviews!
is there any chance of getting a text transcript?
Here's what I had time to start this morning. Formatting sucks and it' hasn't been gone though too carefully for accuracy. Hope it inspires...
[Don’t tell anyone I’m freeee…. Don’t tell anyone I’m freeeeee….]
Will: Hello and welcome to BSDTalk #46. It’s Friday, May 19th, 2006. We just have an interview, so we’ll go straight to it.
Well today on BSDTalk we’re speaking with David Gwynne, and he is an OpenBSD developer. I want to thank you for coming on to the podcast. This year you were at BSDCan. I unfortunately couldn’t make it. So, I was wondering first if you could answer some general questions about BSDCan: what was the experience like for you, how long were you there, the general attendance, talks, social events, generally how you thought it went…
David Gwynne: To be honest, my biggest impression of BSDCan was coming through US customs on the way. They held me up and were a bit curious about all the equipment I had in my bag there. Also, the flight was pretty long. Coming from Australia, it was like a 12 hour flight from Tokyo and I’d had about…no sleep by the time I arrived in Canada. But yeah, it was fine. I haven’t really been to many conferences [undecipherable] so I’m not sure how I’m supposed to compare it to other ones.
W: Did you go to a lot of the social events?
DG: One or two of them. I mostly hung out with the other OpenBSD developers that were there, and we tend to do our own thing sometimes. But generally we went to the social events.
W: How would you compare it to the hackathons?
DG: Extremely different, because at the hackathons it’s more about small discussions where you’re trying to solve a certain problem and you just sit and write code most of the time while BSDCan was very much a passive experience I found. Apart from presenting, it was just sit and listen basically. In between talks it was good to be able to bounce ideas off people and such, but, yeah, it’s a world of difference.
I would like to see an interview with theo.
" I would like to see an interview with theo."
Evryone would like but Theo should work not talk and talk and talk ....
Linus can talk and talk and talk ...
Sp maybe interview Linus
Linus does not code a lot anymore these days. Talking (mostly to developers) is his day job now. So let him talk all he wants.
Quoting Linux himself:
"Well today what I do mostly is actually communication. I started out as the main developer but these days what I do is act as the central point for other people who do a lot of development and I gather it all together and basically communicate with people what needs to be done and so on."
source of quote
Not sure Linus would be that relevant to BSD, as he really doesn't have much to do with it. The only thing that might be interesting to me is why he didn't consider using 386BSD back in 1991. Was it due to the AT&T lawsuit or were there other reasons?
W: And what did you speak about at BSDCan?
DG: The talk I did was on sensors and bio in OpenBSD. Sensors are basically just anything environmental about your system and the levels of redundancies that your hardware has. Like if you have three power supplies and one of them goes off line, the sensors framework is there to report it. And bio is about managing your RAID sets. It’s a very basic level of management, but it’s at least some management and doesn’t rely on any vendor tools to do it.
W: In your opinion, how mature do you think these are?
DG: The sensors framework has been there since 3.4 or 3.5 and we inherited it via NetBSD. I think grange did the work to bring it in. But, it’s only been in the last six or eight months that we’ve actually really tried to write drivers for it and bring it up to speed. To be honest, it is a bit raw still. It needs a lot of work, and we’re looking at that.
Bio is totally homegrown. It’s only been around sort of since the last hackathon, and it’s remarkably useable. Yeah, it just works.
But yeah, sensors needs some work, especially in the userland part. The sensors daemon needs a rewrite basically.
W: Yeah, one of the issues I’ve had with sensors is it does a wonderful job of listing fans and other things, but I’m not sure which fan is which in the sense of mapping what you get out of sysctl with the actual devices on the board. But I guess that’s a problem no matter what.
DG: It depends on which hardware you have in your system. On a lot of the desktops and lower end server stuff, they have these very standard chips that can be hooked up in a variety of ways. So people will stick in this really, really dumb chip and hook it up to temperature sensors, and all we know about that chip is that it has four fans on it. So we enumerate them “fan one, “two”, “three”, and “four”.
But if you go up to the higher end of the spectrum of hardware, into the SCSI realm, you can actually query the hardware for the names of devices. And that’s what we present in the sysctl tree. So, if you look at esm or ipmi for example, it’ll actually say “baseboard fan 1” or “power supply 2” or something like that.
We do our best, but at the low end, we can’t tell what it’s physically plugged into so we just say what it is hooked up to, not where it is.
Post a Comment