hpr-knowledge-base/hpr_transcripts/hpr0825.txt

Episode: 825
Title: HPR0825: Jamey Sharp Interview at X.Org Developer Conference (XDC) 2011
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0825/hpr0825.mp3
Transcribed: 2025-10-08 03:05:53

---

Hey all, this is Marcus again.
So this past week was the Exorg Developers Conference in Chicago, Illinois in United States.
This is the yearly conference where the Exorg guys get together and geek out basically.
Anyway, so while I was there, I managed to round up four interviews with developers and
I thought that y'all might like to hear them.
I enjoy this conference.
This is the second one I've been able to go to.
The thing I like about it is that these guys are really smart and they're really fun.
They're a cool bunch of guys and they're really productive.
If you check out the mailing lists, you know, Mesa, Exorg Develop, DRI, XCB, these guys are
machines.
They just crank stuff up and considering how few of them, they're actually R. The amount
of work that gets done is incredible.
So anyway, I wanted to do some interviews to get people an idea of who the Exorg guys
are.
So anyway, I hope you enjoy these interviews and yeah, guys, this is Marcus again.
I'm going to sound retarded starting out, but this is my third podcast for Hacker Public
Radio.
I'm sitting here with Jamie Sharp at the Exorg Developers Summit.
This one's the Ex Developers Conference.
Is this the conference?
Yeah.
I mean, it summits the European one.
Okay.
2011 today is Wednesday, the 14th.
That sounds right.
Okay.
Got a story of interviews.
Jamie was the first one who was willing to sit down with me as I fumble through this.
So anyway, so this little one, this is it.
So you want to introduce yourself, give a brief overview, history, so I'm Jamie Sharp.
I got involved in X in 2001 when I was sitting, we used to have this weekly sushi lunch
of various people around the Portland Oregon area and Keith Packard and Bart Massey would
show up and Bart, Bart's been my advisor in my academic advisor and actually I met
in a year before I started at Portland State School.
So he is really a mentor for me for a long time.
And so I'd go along with him to these sushi lunches and one day, you know, Thursday
sitting there at sushi and Bart and Keith talking about the sorry state of X-Lip.
And here I am, this poor undergraduate student and they turn to me and say, hey, Jamie,
you should fix this.
And I didn't know any better, so I said, okay.
And off I went.
And for extra bonus points, Bart then said, and you should do it in M4.
So you're stabbing in a forehead, but like a pencil or something.
But again, I didn't know any better, so I said, okay, apparently like that weekend Bart
Keith were talking on the phone and Keith's like, I can't believe you did that to him.
And Bart said, you're right, on Monday I'll tell him, you know, he doesn't have to do it
in M4.
And so Bart comes to me on Monday and I'm like, but I already did it.
So I had a working prototype, you know, over the weekend, I mean, it's the day I'm
like, boy.
Well, the X protocol is not that complicated.
I mean, it's not like I had, you know, all of the core X protocol let alone any extensions,
but I had something that could put up a window, right?
It's not that hard.
Which was the thing that was really irritating all along about X-Lip is it's solving a problem
that is not that hard and it's doing it a really, really hard way.
Hmm.
So that was the history there.
Okay.
That's enough.
Wow, that's pretty good.
Yeah, I don't know much about the X-Lip protocol stuff.
So I guess I need to dig into it a little bit more and find out.
That's, of course, one of the, I mean, you've been working on documentation.
That's one of the best documented parts is all these bits of protocol.
So anything you want to know about the protocol is in there somewhere.
Is in there somewhere.
That protocol for X-Lip is, I forgot how many pages it is.
It's quite big though.
So the protocol for the core protocol for X, yeah, that's 100 and something pages.
The X-Lip manual on the other hand, is that the one you can lie like 15 manuals or used
to be able to?
Yeah.
Okay.
Alright.
Maybe that's what I think of when I hear X-Lip, because that's just, maybe that can just
run the screen in the other direction.
Yep.
That's the correct reaction to X-Lip.
Oh, okay.
Okay.
We probably shouldn't be seeing it because part of my goal was to bring new developers
into X-Lip.
So if we probably shouldn't scare them.
Well, you know, I mean, so my, the history of my involvement in X has always been trying
to take the code and make it simpler.
If you wanted to summarize everything I've done, that's a summary that works for everything.
Have you had good luck doing that?
Mixed luck.
X-C-V has been pretty successful.
Every distro, every Linux distro, or at least every major one, and Solaris, no S10, basically
everybody now is shipping X-Lip that's built with X-C-V.
Okay.
So what is X-C-V?
So X-C-V is X-Proticle-C binding, and that's the thing that that, that sushi lunch
led to.
I mean, they said X-Lip sucks.
We need something that just does the core protocol, or just does the X-Proticle, and that's
it.
And that's what I built.
And Bart suggested calling it X-C-V, and that's the name we've gone with.
Okay.
So the whole, like, because X-Proticle itself is asynchronous?
Or is it synchronous?
Because you got, like, three or four back-and-force between a client and server every time you try
to do anything, right?
Well, no.
So the X-Proticle is actually really cool from the protocol design standpoint.
One thing I always find interesting.
According to JG, the, it jumped at us, the initial announcement for X went out on
use net in June 1984, beginning of June, which, which puts it, like, three weeks before
I was born.
So that's always kind of entertaining.
The current version of the X-Proticle that we're using, and the current version of the
server and client libraries, and, and a lot of the, the infrastructure in X, dates to
September 1987.
X-Eleven is 25 years old.
This protocol has survived 25 years, and there's, there's a reason it survived that long.
It's, it's actually really well designed.
So X, X, X, X-1 came out in 1984, and X, right now we're using X-Eleven.
Oh, it's 11.
So in three years, we had 11 versions, right, and then since then we've had basically nine.
Right.
Because by the time they got to, you know, this X goes to 11, right, by the time they
got to 11, it was actually in really good shape.
I mean, there, I think the biggest thing that's made the X protocol version 11 survived
this long is that it had a good extension mechanism.
So yeah, there were, there are lots of things that are busted about the core protocol.
All of the drawing APIs, all of the text APIs, a bunch of stuff in the core protocol.
Basically all of the input APIs, you can say most of the core protocol is not useful in
today's environment, but it doesn't matter much because the extension mechanism that
they built into the core protocol has led us do better without changing the protocol itself.
Okay.
There's, I think I saw there's 20 or 30 total extensions.
I mean, not all of them are used.
Yeah, there've been a lot that have shown up over time.
It could pull out a laptop and X-dippy info and find out, you know, what the list of extensions
on a particular server is.
There are extensions that have come and gone.
Maybe one of the best known among X developers or the older X developers, anyway, is, I think
it was called Figs or OPEX, the Figs Extension to X, which was an early attempt to add 3D
to X, and obviously OpenGL completely killed it.
What did it come out about the same time as OpenGL, or it came out and then OpenGL came
out and they said, oh, okay, this is much older.
I mean, by the time I got involved in X, PECS was already so defunct that, you know,
so I don't really know.
You could ask Keith, right?
Okay.
Maybe I'll be able to sing a little bit of time for him and pick his brain.
Oh, that's cool.
I didn't know what that one.
There've been a whole bunch of things.
There was, I don't know if you've heard of DisplayPoseScript, which is the idea is to use
it.
It's a DPS extension, right?
Yeah, yeah, yeah.
And so that came and went.
I did documentation for that one, and I don't think that one would get used, but, you know,
it was good.
It was good to exercise.
Keep everything updated.
There's a multi-buffer extension, but along the double-buffer extension.
I remember the DBE double-buffer one.
There was a multi-buffer extension.
There was a multi-buffer extension, really.
That got, finally, purged from the server just last year, I think, really, but nobody
was using it.
Okay.
All right.
But yeah, so this extension mechanism was really great, and I think it's contributed a
lot to extra-living this, but beyond that, other things that are really great about the
X Protocol design, a well-designed client can run for a long time without getting any
responses from the server.
A lot of the requests that a client might want to do, you just send them and sort of forget
about them.
The server will do them.
You don't have to wait for any responses to come.
Sooner or later, we have to worry about a timeout or anything like that.
Not only do you not have to worry about a timeout, but I mean, X is designed as a network
protocol so that you can use it across high latency links, use it across an ocean if
you want to.
Connection dies.
It comes back.
Okay.
As well?
Well, no.
That's something that has always needed special client support, and people could do it, but
nobody's ever cared enough.
So, we call that migration and replication, and there's only one application I know of
that can do X migration and replication, and that's Xemax.
But the idea is, generally, you might want to have an application open a connection to
two different X servers, and display basically the same stuff on both of them.
That would be replication.
And you might want to be able to say, well, I've got this application that's showing up
on my screen right now, but I'm moving over to that machine, so I want to move the application
with me.
Yeah.
In fact, there was a summer of code project a few years back to do something that's
like a new screen, but for X.
I know.
I think he got it to work, but I don't know that anything's happened to us.
Yeah.
Because I would be really cool.
I would really like that.
A lot of people agree.
I mean, it's a, I want to say it's a popular thing to want.
A lot of people don't think about it at all, but among other things, I think it's
among the things that most people don't think about.
That's one of the most popular.
Does that make sense?
All right.
It's one of the most popular things that people don't think about it.
Yes.
Yeah, I'll pull on that later.
All right.
What else?
I got a whole list of questions here to ask people.
Let's see what else.
Help?
Right.
You see, because one of my thing is I'm trying to pull people in.
Yeah.
And you're one of the people I pester when it, because XCB is actually very popular among
the people.
Hey, where can I help?
And they say, look through the list of things all over.
And they say, ooh, XCB, that's one's kind of cool.
So basically, throw them up with fence at you, which I shouldn't be other guys.
And then it turns out I'm always swamped.
And so I'm not so good at responding.
But I think I've said to you an email before, the task of connecting people who want to help
with people who need help is a really valuable task all by itself.
It's a really cool skill.
Yeah, finding, being able to care for people who have the time to be able to help them is harder.
Yeah.
Yeah.
Yeah.
So there's this kind of self-defeating thing, right?
And that the people who need help are too busy to help the people who might help them.
Yes.
Yeah.
Because when you're bringing people up, I mean, and you take a hit because you've got to spin them up.
And it takes effort.
So is there anything that people who want to help can do?
Or they can, I mean, for those listening who are interested in helping out XCB,
whatever, how can they get involved?
Realizing that some of them probably know the way around it.
Okay.
Most people listening probably know the way around a compiler that may not know the...
probably don't know the intricacies of X or something.
Yeah.
What you'll find is that the people in the X community are very willing to help you figure out
where you need to go hack to accomplish something.
But you need to be persistent.
I love this expression of getting lost productively.
That I think is actually the most important skill is you're going to get lost in the code base.
And that's a good thing.
Be willing to be prepared to spend time just kind of exploring,
getting a handle on where things are.
And I mean, you're not going to learn everything about X.
There's too much, no person, not even the...
Most chief understands it all.
Not even the most expert person in that conference room back there has any idea what most...
So it's okay to not understand the whole picture?
Absolutely.
But spend some time getting both the high level of view and getting an idea of the pieces that are most closely related to what you're trying to work on.
And just don't expect to jump in and say, oh, this is the obvious place to do this.
And people have crucial fix in a couple hours.
That's not going to happen.
This has a reputation in some areas for being hard to talk to people,
I guess, find out who to talk to and people kind of developers being very almost established on.
They found that that's actually not the case.
Most of the X people on IRC channel and the mailing list, especially here at the conference, are actually kind of cool people.
They're very cool. They're easy to talk to.
They're kind of fun, actually.
I think the key thing about that is, in this audience probably knows that already,
but reading essays like how to ask questions this smart way,
there's Eric Raymond's essay on the topic and there's Simon Tatham's similar essay on the topic.
I can look up those URLs.
Okay.
I know him, Simon Tatham.
You've probably played his puzzles, the SGT puzzles,
or you've possibly used Putty on Windows.
Oh, I guess I have.
Those are the things that he's famous for.
Okay. All right. I have used Putty.
Okay.
I can recommend his puzzles as well.
I could.
Okay.
Very cool.
So we can people help.
The most general answer is yes, absolutely.
There's tons of work to do.
My ongoing pushes have been for throwing away code.
Because it's September 1987 is the era that a lot of this stuff dates to.
Last year, I submitted a patch that turned out to fix a bug that was in X-11 release one in September 1987.
And nobody had noticed it for what would that be 22 years?
I can't do math.
Apparently it wasn't a showstopping bug.
No, no, it wasn't a terribly important bug.
But I'm still proud of having found it.
Okay.
Getting the award for oldest bug fixed this year, you know.
That's love.
So there are lots of opportunities for that kind of cleanup.
And the trouble is, I think the big trouble with attracting developers is
this is plumbing.
The plumbing metaphor.
I'm sure there was a conference shirt here from last week.
The plumbing metaphor, I first heard from my dad who was a general contractor for a number of years.
And actually did plumbing among other things.
And it's the stuff that you don't notice until it breaks.
Yeah, no one notices when X is running smoothly.
Right.
I just noticed it.
Why can't I get this to work?
Yeah.
Which, you know, if you have a few minutes, how can X developer today?
Well, if I'm a beard.
Yeah, that's people might appreciate that more.
Send a thank you note to someone who's actually fixed a bug you care about.
That'd be great.
That'd be cool.
We don't see here enough people hopping on to say thanks for all the work that you do.
And that's generally true of all this plumbing stuff.
Linux kernel, X, D bus, you know, anything.
What you get is complaints.
And that's kind of it.
Yes, true.
No one appreciates exactly how much work really goes into all that.
Yeah.
You see the problems.
So true.
So you guys listening?
Yeah.
Yeah.
Show some appreciation for the Xbox.
They're pretty cool.
And they, I don't get any credit for what they do.
Ah, cool.
Well, anything else in particular you'd like to talk about before we...
Before I let you get back to the topic that's going on right now, actually.
I think that's it.
Cool.
Thanks for the interview.
Ah, thanks for, uh, thanks for taking the time.
Again, that's Jamie Sharp.
And, uh, yeah, she wanted some more up guys.
And some beer.
Actually, you're not a beer guy that's so much better than I.
I'll do cider.
Cider?
Yeah, like cider.
Cider's good.
So, cool.
Well, all right.
I guess we're done here.
You have been listening to Hacker Public Radio at Hacker Public Radio.
We are a community podcast network.
The release of shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener by yourself.
If you ever consider recording a podcast, then visit our website to find out how easy it really is.
Hacker Public Radio was founded by the digital dog pound and near Phenomenal Computer Club.
HPR is funded by the binary revolution at binref.com.
All binref projects are proudly sponsored by linear pages.
From shared hosting to custom private clouds, go to lunarpages.com for all your hosting needs.
Unless otherwise stasis, today's show is released under a creative commons,
attribution, share a line, lead us our lives.