Carl Malamud: Internet Talk Radio, flame of the Internet. This is Geek of the Week and we’re talk­ing today with Bob Hinton, who’s man­ag­er of Internet engi­neer­ing at Sun Microsystems. That’s the group that comes up with the TCP/IP code that’s in your SPARCstation. He’s also the Area Director of rout­ing for the Internet Engineering Steering Group. and he co-chairs the SIP effort, the Simple Internet Protocol. SIP is one of the key con­tenders as the can­di­date for the IP next gen­er­a­tion, IPng as it’s being called. Welcome to Geek of the Week, Bob.

Bob Hinden: Hi Carl. Thank you. 

Malamud: Maybe we could start by you can tell us a lit­tle bit about what SIP is and maybe how that dif­fers from the cur­rent Internet protocol.

Hinden: Well SIP is real­ly designed to be a step evo­lu­tion from the cur­rent IP pro­to­col. The notion behind it is to take a look at what needs improve­ment, and the thing that start­ed all of this was hav­ing a pro­to­col which could sup­port a larg­er Internet, had larg­er address­es, had bet­ter rout­ing facil­i­ties, and take a look at what IP had, what worked, what did­n’t work, and do some­thing which improves it a lit­tle bit but does­n’t take any rad­i­cal steps. It sort of tries to take a low-risk back­wards com­pat­i­bil­i­ty step.

Malamud: So, you just take…we need big­ger address­es, you just dou­ble the address size and we’re done. What’s…what’s the big deal?

Hinden: I guess it— Maybe that’s what we thought too. There’s a lot of sub­tle issues that have to be dealt with. We’ve sort of tak­en some things out of the head­er, restruc­tured things a bit, moved some of the things that aren’t used very much to option­al head­ers to try to increase the per­for­mance. We’ve end­ed up with some­thing which while it cur­rent­ly has address­es which are twice as large, the over­all head­er’s only four bytes longer than IP, so it’s still rel­a­tive­ly small and rel­a­tive­ly simple.

Malamud: Well let’s go through a cou­ple of those issues. You say the address­es are twice as large but the Internet is dou­bling every year. Did you just buy us an extra year by dou­bling the headers?

Hinden: Ah, that’s a good ques­tion. When you dou­ble the size of the address­es you don’t dou­ble the num­ber of address­es, you mul­ti­ply them togeth­er. Someone made a sim­ple obser­va­tion that the cur­rent— You know, we have a cur­rent sys­tem which will prob­a­bly scale to…I guess we have total of a cou­ple mil­lion net­work num­bers. And you could prob­a­bly have many more than that hosts. If you could allo­cate the address­es com­plete­ly flat­ly, SIP would allow you to have four bil­lion of the cur­rent Internets. So anoth­er way to say this is that every per­son on Earth today could have their own Internet as big as the cur­rent Internet tech­nol­o­gy will grow. 

Malamud: Or alter­na­tive­ly there’s enough room in the SIP address space for every pro­ton in the uni­verse, I believe, or some num­ber of the uni­verse of that size.

Hinden: Well, the uni­verse is a pret­ty big place. But certainly—

Malamud: Why do we need such a big address space?

Hinden: We need a big address space for two rea­sons. One is that there’s going to be a lot of things we need to address. The sort of a com­mon notion that every­where there’s a tele­phone today there’ll be a net­work. And the only thing that— That esti­mate might be too small. But in some sense any­where there might be a com­put­er you might want to be able to address it. 

You also need big­ger address­es because you can’t uti­lize them opti­mal­ly so you need to allow room for cre­at­ing hier­ar­chies and admin­is­tra­tive structure. 

Malamud: And so we don’t need an address space big enough to have one address for every per­son, we need more room than that in order to pro­vide that structure?

Hinden: We prob­a­bly need an address space which is big enough that every per­son can have a num­ber of com­put­ers. And exact­ly what that num­ber is no one knows, but we need some­thing that will pro­vide enough growth in the fore­see­able future. Sort of the ques­tion that comes up is do we need enough address space to…that we could nev­er run out in any cir­cum­stances. And that’s… I believe in build­ing things which run over in the domain which we can sort of under­stand and fore­see but it’s real hard to pre­dict what things will be like a long way in the future if the indus­try and the tech­nol­o­gy changes very quick­ly. If we look back ten or twen­ty years, you would­n’t’ve imag­ined we’d be where we are today. So I sus­pect we can’t real­ly imag­ine what it’s going to be like twen­ty years from now. So I think if we design a solu­tion which looks like it can be can scale as far as we can rea­son­ably imag­ine today I think that’s adequate. 

It’s also an issue of solu­tions which tend to work well in today’s envi­ron­ment that scale are much bet­ter than solu­tions which build in a lot of inef­fi­cien­cy because they might be need­ed lat­er. Those tend not to solve peo­ple’s prob­lems very well.

Malamud: So you have a sim­ple Internet pro­to­col list, as you call it. But we’re ask­ing more of our net­work play­ers these days. For exam­ple, Steve Deering, your co-chair on the SIP Working Group is the father of multi-casting. By remov­ing some of that func­tion­al­i­ty and sim­pli­fy­ing things are you going to make it hard to sup­port mul­ti­cas­t­ing, for example?

Hinden: No, in fact just the oppo­site. We’re tak­ing the things we think are impor­tant, like mul­ti­cast in par­tic­u­lar, oth­er things like mobil­i­ty and auto­con­fig­u­ra­tion, and we’re build­ing those in from the start. There’s a lot of work going on to essen­tial­ly add those things to the exist­ing pro­to­cols, the exist­ing IP ver­sion 4 we have now today, but when there’s a large installed base, you have to design what— You can’t change the pro­to­col in ways that’re incom­pat­i­ble. When you get a chance to do some­thing which there isn’t a big installed base, and if you can pro­vide those things at the begin­ning, then you can require that all imple­men­ta­tions do them from the start. So by deploy­ing in par­tic­u­lar SIP, we believe that we’ll be build­ing a base that all imple­men­ta­tions will do mul­ti­cast, all imple­men­ta­tions will be easy to con­fig­ure, they’ll have a pro­vi­sion for sup­port­ing real-time traf­fic with flows. You know, there is some oppor­tu­ni­ty here to do the things that need to get done.

Malamud: Well how for exam­ple do you sup­port auto­con­fig­u­ra­tion. What is it in SIP that makes it easy to do that kind of thing?

Hinden: Well, I think the biggest thing is again we get to, because it’s an area that IP ver­sion 4 does­n’t do, we get to define some new con­trol pro­to­col mes­sages which allow host and routers to exchange the right infor­ma­tion to do that.

Malamud: What about sup­port for real-time data, now that we’re see­ing video and oth­er isochro­nous data on the net­work. How does SIP pro­vide that support?

Hinden: Well SIP essen­tial­ly, with­out any­thing new, makes it work as well as what IP ver­sion 4 does today. SIP has a place­hold­er for real-time traf­fic called up a flow label­er, flow iden­ti­fi­er, which is intend­ed to allow—with some set­up or nego­ti­a­tion allows state infor­ma­tion to be put into a router to either iden­ti­fy the traf­fic or to asso­ciate it with a par­tic­u­lar flow so we can pro­vide some guar­an­tees of ser­vice and fair queu­ing. This is an area which is more in the research com­mu­ni­ty but we’re con­fi­dent enough in the idea that we think it’s impor­tant to allo­cate some space in the SIP head­er to allow that infor­ma­tion to be used lat­er as the work gets done. So we think it’s prob­a­bly the answer—you know, there will be a solu­tion based around flows that we’re pro­vid­ing the facil­i­ty to add that with­out hav­ing to change the protocol. 

Malamud: That’s one research area that you’ve looked at and said that looks fruit­ful and we’re gonna make room for that. Are there research areas you’ve looked at and said well, we don’t think that’s going far enough and we’re going to explic­it­ly ignore this?

Hinden: Well, we’ve had the philosophy—and I give Steve Deering quite a lot of cred­it, which is he’s resist­ed putting things in that there aren’t very clear uses for or we have a good under­stand­ing of how they work. Um—

Malamud: What’s an exam­ple of that kind of thing that you’ve resisted?

Hinden: One exam­ple is there’s a field in IP called Time To Live, which is essen­tial­ly the num­ber of hops or routers that a par­tic­u­lar pack­age can go through. It’s used for loop detec­tion. So if there’s a loop, the pack­et won’t go around the loop for­ev­er. When Steve was first design­ing SIP, peo­ple said, Does that field need to be big­ger?” And cur­rent­ly it’s eight bits and you can have 256 hops, which in the cur­rent Internet is by a fac­tor of…probably in most cas­es sev­er­al orders of mag­ni­tude but even in the most extreme cas­es prob­a­bly fac­tor of four.

Malamud: Yeah, twen­ty or thir­ty hops is real­ly the out­side poten­tial diam­e­ter and that’s even…that’s real­ly strange.

Hinden: Yes. But there were some com­ments that well gee, let’s make the field big­ger, let’s make it so it could be six­teen bits or sixty-four thou­sand hops, and Steve and some of the oth­er SIP devel­op­ers resist­ed doing that because we just don’t think that’s… While yes, it would make the pro­to­col more gen­er­al, we don’t you can build Internet works where the traf­fic has to go for tens of thou­sands of hops. That’s just not gonna work. So we think hav­ing some con­straints on the pro­to­col that will con­strain the topol­o­gy of the net­work is in fact a good thing. 

In some sense keep­ing the address size to sixty-four bits is also a sim­i­lar thing. If you don’t under­stand the— If you don’t have absolute answers to all of the ques­tions, one approach is to make things so gen­er­al. You could have either extreme­ly large address­es or variable-size address­es. And that’s sort of nice because it keeps it open-ended but you pay a price in per­for­mance and in table size. And if you can come up with a more lim­it­ed more lim­it­ed size address that still address­es every­thing you can rea­son­ably imag­ine, I think it’s a bet­ter engi­neer­ing solu­tions. So a lot of areas we’ve resist­ed mak­ing things gen­er­al because just to make them gen­er­al there had to be a real rea­son. You know, if some­one could come and point out rea­son­able sce­nar­ios why what is there won’t work, or isn’t scal­able enough, does­n’t have enough life­time, we’re real open to change but there has to be pret­ty con­crete reasons.

Malamud: The Internet has moved beyond being a research net­work. It’s very much an oper­a­tional envi­ron­ment. Many of us real­ly depend on that. I know your busi­ness depends on it and cer­tain­ly mine is absolute­ly depen­dent on the Internet work­ing. How are we gonna do a tran­si­tion to SIP in a way that keeps the cur­rent world working?

Hinden: Well, one of my major inter­ests in work­ing in the IPng are­na, and I’ve been involved with some oth­er pro­pos­als which have sort of evolved into the cur­rent SIP group, is to do things that have back­wards com­pat­i­bil­i­ty, make tran­si­tion easy.


Malamud: How do you make IP ver­sion 4 and SIP worlds talk to each oth­er? Or do you do that? I mean, do you just say, We’re going to tran­si­tion this net­work on a cer­tain day,” or…

Hinden: No. We’ve built as many things in that are…where there was no rea­son to change them. Like the way do frag­ment pack­ets. We’ve used the same seman­tics, so it’s easy to map from one to the oth­er. The areas that are obvi­ous­ly dif­fer­ent are address­es, and we have a tran­si­tion scheme where for the peri­od of time until IP ver­sion 4 address­es are no longer unique glob­al­ly in the eco—the word we tend to use—that we will embed one of those in a SIP address—low order thirty-two bits, and this allows IP ver­sion 4 host to essen­tial­ly address SIP hosts it’s a rel­a­tive­ly easy map­ping to map between them, so we’ve actu­al­ly designed and imple­ment­ed code that can trans­late from one pro­to­col to the other.

Malamud: So the address of a SIP host is, if you take off the high thirty-two bits and there’s some pre­fix, what’s left is actu­al­ly a valid IP address.

Hinden: Yes. And it’s our intent that until the world decides that IP address­es are no longer unique every­where, essen­tial­ly when they would have to get reused, that all SIP hosts that want­ed to com­mu­ni­cate with IP ver­sion 4 hosts would essen­tial­ly be assigned an IP address.


Hinden: I guess the way I think about it is that I don’t want to require things to have soft­ware upgrades if they don’t need the func­tion­al­i­ty. So that…I mean com­put­ers, they don’t wear out but there comes a point where you throw them away. Or you know, you replace them for oth­er reasons—the main­te­nance cost gets too high. When you put in a new com­put­er with new soft­ware, it should come with a new pro­to­col. But we don’t think there’s a need to force every host who does­n’t need to talk over the glob­al Internet to do a soft­ware upgrade.

Malamud: So the eas­i­est part of the tran­si­tion is while the IP space is still glob­al­ly unique.

Hinden: Yes. This gets a lot hard­er if we haven’t deployed the new pro­to­col before we run out of addresses.

Malamud: How far along are you now?

Hinden: Well, I think we’re pret­ty far along. The thing… Maybe what this comes down to in all the dif­fer­ent choic­es is the amount of risk asso­ci­at­ed with each pro­pos­al. I think SIP has the advan­tage that it’s real sim­i­lar to IP. If you can under­stand the cur­rent IP you can under­stand SIP real clear­ly. It’s real sim­ple. It has some new stuff in it but the basic oper­a­tion is real­ly the same ideas. A lot of the ele­ments in the head­ers are exact­ly the same. And we have…I guess about sev­en or eight dif­fer­ent imple­men­ta­tions now. Most peo­ple have found that it’s real­ly very easy to take their exist­ing code and to add SIP to it. And it—

Malamud: And is this the case for for machines that maybe aren’t as network-aware as a SPARCstation? Can you do this on DOS for example?

Hinden: Yes. We have imple­men­ta­tions on DOS and Windows. There’s VMS. There’s a Mac imple­men­ta­tion. There’s sev­er­al fla­vors of Unix.

Malamud: And have you test­ed these against each oth­er? Do they actu­al­ly work?

Hinden: Yes. We had what we called a SIP inter­op­er­abil­i­ty event before the pre­vi­ous IETF meet­ing. We did a demo then. We did a demo at this IETF meet­ing. So we’ve actu­al­ly run the imple­men­ta­tions against each other.

One of the real nice things about SIP is that because it uses IP ver­sion 4, it actu­al­ly encap­su­lates your tun­nels as part of its nor­mal mech­a­nism. You don’t need to deploy any new infra­struc­ture in order to test it. So it means we get to test it over the Internet as nor­mal oper­a­tion. It’s sort of— We don’t have to put in spe­cial things to test it, it’s nor­mal mode is to run this way. So it’s been real easy to plug machines in and do the test­ing. You don’t have to fool around with deploy­ing lots of new things in order to set up the com­mu­ni­ca­tion paths.

Malamud: You and sev­er­al oth­ers at Sun are invest­ing a con­sid­er­able amount of time work­ing on this. Why does it make sense for Sun to do this instead of wait­ing for the stan­dards to come out and then just imple­ment­ing them?

Hinden: Well, I— My view on this is that in this industry—I call it the the inter­net­work indus­try, com­mu­ni­ca­tion industry—you know, it’s not a place where you win by having—or are suc­cess­ful by hav­ing pro­pri­etary solu­tions. You win— You become— You want to become a leader in the tech­nol­o­gy and you do it by doing things and hav­ing lots of oth­er peo­ple use them. I think the areas where—I’ve been at Sun for I guess…it’ll be eigh­teen months in a lit­tle while. So I had been had been a Sun cus­tomer before I worked there. And I think the areas where Sun has had great suc­cess is where Sun has devel­oped tech­nol­o­gy and then worked with oth­er com­pa­nies and seen it deployed on a very large scale, and not made any claims of…not licensed it, just make code and specs freely avail­able. And I think in the Internet world it’s the same thing. You are suc­cess­ful by get­ting oth­er peo­ple to use the same pro­to­cols, or the same tech­nol­o­gy. And if you then also deliv­er good prod­ucts around them, you will be suc­cess­ful. So it’s not an area where you want to do things and don’t tell any­one what you’ve done, you want to be as coop­er­a­tive with oth­er peo­ple. So Sun’s inter­est in this is advanc­ing the tech­nol­o­gy and pro­vid­ing a solu­tion which we think is best for our cus­tomer base, of course. I mean, there’s cer­tain­ly self inter­est in this. But we would like to see the IPng process end up with a solu­tion which we think pro­vides good solu­tions to our customers.


Malamud: You say the key is an open solu­tion, every­one can imple­ment it. It would seem to me the log­i­cal thing to do would be go and get the inter­na­tion­al stan­dard, CLNP—the Connectionless Network Protocol which is already wide­ly deployed around the world, and just use that. Why aren’t you using the ISO standard? 

Hinden: Well that’s a good ques­tion. That’s the ques­tion the Internet com­mu­ni­ty asked. And I gave this quite a lot of thought, and the prob­lem with that is that I think some of the com­mon assump­tions that it’s wide­ly deployed and it’s all done aren’t quite right. There’s a lot­ta details that aren’t done and all of this stuff is in the details. It’s not just the main pro­to­col, it’s all the con­trol pro­to­cols and the rout­ing and the imple­men­ta­tions and the testing.

Malamud: Well what kind of details are miss­ing in the…in either the CLNP com­ing out of ISO or the mod­i­fied ver­sion known as TUBA that the Internet com­mu­ni­ty is con­sid­er­ing as a pos­si­ble candidate?

Hinden: Well, where I see the problems—this isn’t a direct answer your question—but where I see the prob­lem is that CLNP is real­ly IP five to ten years ago. It’s…you know, it’s been sort of slow in com­ing but there’s noth— It has larg­er address­es but every­thing else is approx­i­mate­ly the same. It’s big­ger but it pro­vides about the same functionality.

And my con­cern, besides— Well I guess two con­cerns. One is that there is there is no, at least in my opin­ion, rea­son­able tran­si­tion strat­e­gy that makes it easy to deploy and makes it easy to oper­ate with the exist­ing IP ver­sion 4 hosts. But the oth­er prob­lem is that I think if the Internet com­mu­ni­ty adopts this the Internet is going to spend the next five years redo­ing all of the things that have been done for IP ver­sion 4, as opposed to spend­ing five years mov­ing the tech­nol­o­gy forward. 

Malamud: So it’s it’s miss­ing mul­ti­cast and flow con­trols, for exam­ple, or auto­con­fig­u­ra­tion, or—

Hinden: It’s miss­ing mul­ti­cast, it has two rout­ing pro­to­cols. IP ver­sion 4 has some­times more than we can count. There isn’t much expe­ri­ence with it. There’s— Maybe this is the final thing, there real­ly aren’t very many users who use CLNP in an oper­a­tional mode.

Malamud: Well ISO has expressed its will­ing­ness to liaise with the Internet Engineering Task Force and come up with a com­bined thing. Now would­n’t be a great polit­i­cal win if we could com­bine ISO and the IETF togeth­er into one super open sys­tem solu­tion? Isn’t it worth giv­ing up some of these flow con­trol fea­tures in order to have this nice rapproachement?

Hinden: Well, I think that would be…for some val­ue of nice,” but I don’t want to sac­ri­fice the exist­ing base to do that. I think TCP/IP has essen­tial­ly won in the mar­ket­place. CLNP OSI has been…the mar­ket has had plen­ty of time to adopt it and to deploy it, and it has­n’t hap­pened. I think there’s— I don’t think I’m the only one with this opin­ion, but I think that if the Internet does not choose the IPng solu­tion, which is based on CLNP, my pre­dic­tion is that CLNP does­n’t have much of a life left to it. I think this is the last big oppor­tu­ni­ty for the com­mu­ni­ty which is push­ing on CLNP.

And again, my view is that I would hate to see the Internet spend five years redo­ing all of the things that have made TCP/IP work over a large scale. You know, there’s solu­tions for large net­works, there’s solu­tions for small net­works, a lot of var­ied imple­men­ta­tions, a lot of expe­ri­ence, a lot of sort of train­ing and books and…a lot of peo­ple invest­ment, I guess, not just soft­ware. Vendors are real good at writ­ing soft­ware. But a lot of peo­ple under­stand it. And I would hate to see us spend a long time redo­ing all that and then at the end of the time be technically—the func­tion­al­i­ty be at the same place we are now, except we could have a big­ger sys­tem. I think the world is not going to wait that peri­od of five years. There are oth­er things hap­pen­ing in the world that peo­ple will come up with oth­er solu­tions and it would essen­tial­ly obso­lete this technology. 

The area that I think is most inter­est­ing is the things that Apple and General Magic and peo­ple are talk­ing about doing around cable TV sys­tems who’re essen­tial­ly putting net­works and com­put­ers in every­one’s hous­es. And I sus­pect those are going to be the areas where the growth comes from. The cur­rent sort of com­mer­cial mar­ket of work­sta­tions and PCs and stuff is cer­tain­ly gonna grow for a long time but there’s like­ly to be anoth­er big step func­tion as peo­ple build very low-cost, very pow­er­ful com­put­ers that every­one gets—go into peo­ple’s hous­es, and those are all going to be net­worked. If we can pro­vide an Internet solu­tion that works in that are­na, then I think every­thing will be will have sort of a uni­fied, glob­al inter­net­work that spans super­com­put­ers down to hand-held devices. If we can’t pro­vide a solu­tion that the peo­ple build­ing those prod­ucts need, then they’ll do their own. And we’ll end up with anoth­er set of incom­pat­i­ble things. So I think our oppor­tu­ni­ty is to pro­vide some­thing which will scale not only in size but also into the kind of appli­ca­tions and the envi­ron­ments that we see the world going to.

Malamud: You have two func­tions in the IETF. On the one hand you’re an advo­cate; you’re the co-chair of the SIP group. You’re also a mem­ber of the Internet Engineering Steering Group, which will be mak­ing the deci­sion about IPng. Does it make sense to have some­one who’s actu­al­ly going to make the deci­sion also be involved in the work, or should you be some­how more neu­tral and kind of wait for the results to be pre­sent­ed to you?

Hinden: Well, it’s an inter­est­ing ques­tion. If you take it to extreme, then any­one who has any opin­ion or any knowl­edge should­n’t be involved in the deci­sion. And that clear­ly does­n’t work because you want to…this is not you know, pick­ing A or B. All of the solu­tions are essen­tial­ly opti­mized for dif­fer­ent things, and the outcome—how well it works, will be…you know, they will do dif­fer­ent things, they will have dif­fer­ent effects. And you clear­ly want to have a very informed decision.

On the oth­er hand you cer­tain­ly don’t want— It’s impor­tant that when the deci­sion is made, it’s impor­tant that it not be viewed from the out­side as an inside job, as you know a back­door solu­tion and it favored insid­ers. So it’s very impor­tant that it be open and fair, and the process that made it be vis­i­ble so it’s essen­tial­ly beyond reproach. And even then that there be an appeals process. And in that sense it’s prob­a­bly rea­son­able for the peo­ple who are obvi­ous advo­cates of par­tic­u­lar solu­tions to step aside from the deci­sion­mak­ing process.

Malamud: Are you ready to decide it? Could you in good con­science say, Okay, SIP is it, we’re ready to go.”

Hinden: Yeah, I’ve decid­ed. I mean, I’m putting my ener­gy work­ing with oth­er peo­ple chair­ing the group. I’m not doing this for fun. It’s a lot of work. I have oth­er things to do. It’s not exact­ly my real job. But I think it’s impor­tant. I think it’s impor­tant for…you know, essen­tial­ly for the Internet, for the coun­try, for the world. I think it’s also impor­tant for the com­pa­ny I work for. I think Sun Microsystems has a stake in the out­come. We have a cus­tomer base, and we I think want solu­tions that work best in that environment. 


I see sort of a cou­ple of pos­si­ble out­comes here. One is that the work gets done and the IESG picks one of the four. I mean in some sense it could be done at any time. There’s always going to be… At any point there’ll be a cer­tain amount of infor­ma­tion and if you wait­ed there would be more. But if you take that phi­los­o­phy then you could wait forever.

Another approach is that there’ll nev­er be a deci­sion. That the four con­tenders will go off and they will be deployed and the world will see four more pro­to­cols. And—

Malamud: Is that all bad?

Hinden: Um, I think it’s…

Malamud: I mean we have X.400 and 822 mail and they work, sort of.

Hinden: Well, and we have AppleTalk and we have IP and we have IPX, and…there’s a long list. I think that there’s a lot of ben­e­fit in hav­ing one major Internet lay­er pro­to­col [crosstalk] that works on a glob­al scale.

Malamud: Is the glob­al con­nec­tiv­i­ty, is that the key goal of doing that? Is glob­al con­nec­tiv­i­ty the rea­son we want one [crosstalk]pro­to­col?

Hinden: Yes. We want one pro­to­col because it makes it so that every­one can talk with each oth­er eas­i­ly, as opposed to all pro­to­cols hav­ing to be implemented. 

Malamud: Well there you have it. This has been Geek of the Week and we’ve been speak­ing with Bob Hinden. Thanks a lot Bob.


This is Internet Talk Radio, flame of the Internet. You’ve been lis­ten­ing to Geek of the Week. You may copy this pro­gram to any medi­um, and change the encod­ing, but may not alter the data or sell the con­tents. To pur­chase an audio cas­sette of this pro­gram, send mail to radio@​ora.​com.

Support for Geek of the Week comes from Sun Microsystems. Sun, the net­work is the com­put­er. Support for Geek of the Week also comes from O’Reilly & Associates, pub­lish­ers of the Global Network Navigator, your online hyper­text mag­a­zine. For more infor­ma­tion, send mail to info@​gnn.​com. Network con­nec­tiv­i­ty for the Internet Multicasting Service is pro­vid­ed by MFS DataNet and by UUNET Technologies.

Executive pro­duc­er for Geek of the Week is Martin Lucas. Production Manager is James Roland. Rick Dunbar and Curtis Generous are the sysad­mins. This is Carl Malamud for the Internet Multicasting Service, town crier to the glob­al village.


Help Support Open Transcripts

If you found this useful or interesting, please consider supporting the project monthly at Patreon or once via Cash App, or even just sharing the link. Thanks.