hpr-knowledge-base/hpr_transcripts/hpr2231.txt

Episode: 2231
Title: HPR2231: linux.conf.au 2017: Rusty Russell
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2231/hpr2231.mp3
Transcribed: 2025-10-18 16:15:23

---

This is HBR episode 2,231 entitled Linux.com.0 2017, RustyRustle and in part on the series
Interview.
It is hosted by Clinton Roy and is about 37 minutes long and Karima Cleanflag.
The summary is Clinton Interview Linux.com.0 creator RustyRustle.
This episode of HBR is brought to you by an honesthost.com.
At 15% discount on all shared hosting with the offer code HBR15, that's HBR15.
Better web hosting that's honest and fair at An honesthost.com.
It's Thursday, the second last day of Linux.com.0.0 and I have a few minutes with RustyRustle now.
So Rusty's currently, his current headspace is very much in the Bitcoin world.
But as I'm personally a little bit sick of anything and everything Bitcoin related, blockchain.
I have asked him to talk about anything, but that's so if you're doing that stuff, why are you at LCA?
What's that LCA for you?
If your technical mind space is in a completely different area now, that's actually a really good question.
LCA is a lot broader than the name would suggest and I think that's a common misconception.
So this conference is a great opportunity to do, not only do a whole lot of side projects like Secan, being the obvious one,
and to catch up with colleagues from around the world.
But it's also an incubator for ideas in future.
There's been a lot of really productive conversations about side projects and things like that.
I certainly wouldn't miss it so well.
So Secan is a collection of sea libraries, sort of based on the Pearl module.
I think I've definitely used a few of the libraries.
I don't think I'm almost certain I haven't contributed.
I know you haven't.
I've been meaning to talk to you about that.
The unofficial Secan motto is Pearlcan, then Secan.
Nice, nice.
So I guess people might know you most from your contributions to the external, particularly around the module area.
So you've recently, so like the ability to insert and remove modules from the external, that is very much your baby.
It was very much your baby.
You have officially let go of that.
Yes, so I will nominally co-maintain her at the moment, but the plan is that I will migrate out of even that.
And then my name will finally be expunged from the maintenance file.
And I was lucky that I found Jessica Yu, who works at Red Hat, who flawlessly submitted her patch,
because she was working on the live patch, then it overlapped the module code.
She submitted her patch.
I reviewed the patch and made a comment, and she corrected my comment.
And so I thought, well, okay, if you could find a bug in my code, then congratulations.
There you should be module maintenance, and of course you declined.
So I approached her against it once later.
That's two proofs of intelligence.
That's right, exactly.
So this is clearly a method that she's the right coder for the job.
So six months later, when I approached her, when she had a little bit more kernel experience,
managed to convince her to come maintenance.
And she's been doing a fantastic job.
Now, it helps, I think, a little bit that I've been so distracted that my maintenance
has been terrible.
And I think everyone's just grateful to have somebody steering the ship.
But the other thing is the module code doesn't move very fast.
It's a critical piece of kernel infrastructure.
So you'd hope that it doesn't change very often.
It can't, right?
Because the vicinity changed that API.
All the modules have to get updated.
That's right.
So we try to do that more than once a week.
And...
So, yeah.
But it does overlap a lot of other areas.
So you're dealing with a very eclectic bunch of people who have different requirements on the module code
and all the architecture, maintenance, and everything else.
So I think it's a fantastic opportunity.
And Jessica's ability in this area has been even better than I expected.
So I am certainly patting myself on the back, being so clever about choosing someone to handle over to.
But I'm sure she deserves to credit in there somewhere.
So why the hinder?
Was it because your work like is moving in different directions?
Or is it just an attempt to streamline things?
Or have you had it with the kernel development process in team?
Or is it a combination of all?
Well, when you put it that way.
So when I like, when I stop working on the next step, I'm joined to start up.
Obviously I wanted to get one finger in the pie just in case everything exploded.
Because that's what happened to the last startup I was in.
So it was once 18 months at past, I think it was clear that at least in the short term,
I wasn't going back to kernel development.
So I felt it was a good time to hand over.
And just looking back at the amount of time that I've been putting in,
it hasn't been up to par.
I've been falling behind on patches.
And the net result was, I don't think I've been able to maintain it.
So it's certainly time to do an organized handover.
And unfortunately, just need to kind of get thrown in the deep end.
Because of course, I promised that I would help maintain it pretty much
through the patch you had there and stop responding.
So it was certainly time for the transition.
But when you've got a project that you're really passionate about,
it's often hard to draw yourself away and go work on something else.
So it was always funny excuses to defer my kernel work.
And I think that was certainly a sign that with my attention elsewhere,
it was good to hand over.
So just before the conference, I went on a hike.
And then after that hike where I'm surrounded by like 10 people,
I come to a conference with like 600 people.
And I wasn't expecting it.
You've been a kernel maintainer now for like 10 years, something?
19.
How is that like now that that is over, normally over?
Have you noticed big changes to how you're living
or have you suddenly noticed all these things?
Like, well, these pressures that you over the years
that they would have slowly sort of been squashed on you
and you wouldn't notice them incrementally.
But now that they're suddenly all removed at once,
have you noticed anything like that?
Yeah, interestingly not.
And sometimes when you leave a job, you get that weight off your shoulders.
You're like, okay, I finally made this decision to leave.
That was great.
Not so much of this because I kind of transition straight across
and dive into something else.
And so I've been so consumed with that,
I haven't had that whole, oh, that's all over.
Plus, I mean, my semi-abandonment of the kernel over time
has meant this has been much more of a drawn-out process.
Yeah, there have been moments where I, you know,
obviously the kernel community is the pinnacle of open source hacking in a lot of ways.
There's a benchmark by which people measure other projects.
And being a part of that has a great joy.
And certainly working with the vast majority of my kernel colleagues
has been an exceptional experience.
And I'm moving from a really big point to a much smaller point,
which is the reason that I joined the company I did,
because they're the only ones who had the kind of level of skill
that could draw me out into another project.
So I think if someone were transitioning from the kernel
onto a project where they were by themselves,
I think that would be a lot harder to find out
about much more difficult to step backwards into all of them.
There's no one around.
But in a way, it does feel a lot like the kernel was 20 years ago.
Much smaller project, smaller community,
and a lot more people who don't care.
So I guess that means hopefully what you're hoping for is in 20 years' time.
All of the blockchain bitcoin stuff will be a base software
that everything else has put on top of.
Well, I certainly see things through a software viewpoint.
I see the stages that Alex went through
and the battles that we had early on
that have now been one so thoroughly,
and nobody even questions it.
People don't ask why are you giving the software away
for free if it's any good?
And these kind of questions that we had in the early days,
and certainly people were asking,
well, why would you code on something?
You could be earning real money.
Those questions, I think, have been thoroughly answered.
In the Bitcoin space, there are a lot of questions
that we don't know the answer to.
And I'm hoping that we have the same kind of successors,
but history never repeats itself exactly.
The same way we never won on the desktop with Linux,
Bitcoin may not go where our straight line would suggest it's going to.
Yeah.
So it would be silly of me,
given that we're at Linux.com for you,
it would be silly of me not to,
at least it's not that you started this whole series of conferences,
like 19 years ago.
Yeah, 19, 1999.
And you self-funded that on the back of your own credit card.
And, you know, it's gone on in leaps and bounds
and you have never, again, had to...
Never again had to handle your credit card and worry.
So, I mean, how does that feel?
I mean, you know, it's like a child that's grown up
and I'm not sure if it's moved out of home yet,
but, you know, how do you feel about starting something
that has had this level of endurance?
Well, it's really interesting.
Last year, for personal reasons,
the first year, I missed Linux.com for you.
And that felt like a leaving home kind of moment in a way.
Now, for years, of course,
it's been run by other people and everything else.
But the consistent level of the conference has reassured me
that this isn't a flash in the pan.
For the first few years, I worried that, you know,
we're going to check the shark at some stage.
It would no longer be the great conference.
Maybe this will be the last great year.
And then we'd look back and go, no, really not as good this year.
We've been in Brisbane for the third year.
We really did try.
It has consistently been a fantastic experience.
And the fact that the conference continued to spite my absence,
certainly has that moment of, wow, you know,
it is its own thing now, and it has been for a long time,
just in a emotional sense.
It is now its own thing.
It has left home.
It has become its own thing.
I think the important lesson here is that I had no idea what I was doing
when I started the conference.
I certainly didn't have the audacity to believe
that we would be sitting here in 20 years time talking about this event
that has become such a landmark.
So I think sometimes you've just got to take the plunge.
And if you're very, very lucky in 20 years,
you get to talk about how great it was.
But the vast majority of things, you know,
it won't be that good, but you'll never know unless you try.
Yep, okay.
Well, I think I've taken up enough of your time.
I think the next schedule started, so thank you very much.
Just thank you.
You've been listening to Hacker Public Radio at HackerPublicRadio.org.
We are a community podcast network that releases shows every weekday, Monday to Friday.
Today's show, like all our shows,
was contributed by an HBR listener like yourself.
If you ever thought of recording a podcast,
then click on our contributing to find out how easy it really is.
Hacker Public Radio was founded by the digital dog pound
and the Infonomicon Computer Club,
and is part of the binary revolution at binrev.com.
If you have comments on today's show,
please email the host directly,
leave a comment on the website
or record a follow-up episode yourself.
Unless otherwise stated,
today's show is released on the creative commons,
attribution, share a light, 3.0 license.