Okay, we can go for the next.
So my talk's a shell script, I'm sorry, should we play game?
It requires audience participation, so I hate that too, but I thought I'd be really
so much of a look.
Is this a networking commit to freebiscity?
Yes or no?
Easy question.
Is that a networking commit?
Okay everyone says yes.
Is this a networking commit?
No?
Okay.
Is this a networking commit?
Like, I know the top strength hit, but it's a great commit, you should go and read it, but
no.
Is this a networking commit?
No.
This?
Probably not.
No.
Is this a networking commit?
I don't think so.
Is this a networking commit?
It's got fibs in it.
That's a networking thing.
Does it matter?
If we're talking about the networking stack should we highlight this?
It's hard to say.
I can say no.
I don't think this is either.
It doesn't have any magic words in it.
Is this a networking commit?
Yes.
Super easy.
Is this a networking commit?
No?
Well, let's see.
So, you know, we've looked at 12 commits, now very quickly, but 12 commits.
And 3BSD commits have a nice format, mostly, where we get an area highlighted.
So, this is NVMe control, like, straightforward.
We get a subject line, and then we get a body that says some things.
This body uses the word TCP, which makes us all think it's networking, but it says NVMe
is where, like, oh, no.
Is NFS a networking system?
Yes.
So, this is probably, so this is NVMe over TCP.
So, this is probably a networking commit.
So, we can talk about that.
See, we can take it.
I started with a demo, but the demo is a four loop, so it's not as impressive as emails.
It's just a shell script.
It gives us how many commits there've been in the last window.
How many we've taken, how many we've rejected.
If I just press enter, it will take it because there's quite a lot of networking commits.
Do you think this is a networking commit?
If you saw it without seeing the previous commit, would you think it would have networking impact?
It's still Chelsea, although, but they might do other stuff.
It's a guess.
Oh, take it.
I don't think this is a networking commit.
I don't think this is an NV list.
Is this a networking commit?
Yeah.
Yeah, Chris loved it.
He doesn't do anything else.
Definitely take that.
So, there's quite a lot going on.
In any given week, you free BSD, there's one to 200 commits coming through.
And this chart is a summary of the reports I've done for the end of last year,
but I made up the chart just based on numbers.
It's not particularly accurate because I'm doing unicode art here.
But yeah, like any given week was 1 to 200 commits across a dozen or so specializations.
And they get very, very, very in-depth, very quickly,
to the point where there's a couple of people in the world,
which could reason about what is happening here.
You know, we're lucky.
We have a big tree.
We've got a lot of consumers and free BSD commiters are automatically subscribed to the free BSD source commits list.
So, some people find out they have a commit bit because they get 300 emails overnight.
And they're like, what the hell is going on?
But other than, you know, a very special set of people on the internet,
no one, one person can reason about this.
Yeah, there's some people in free BSD, but anyone reading the commit mail
is already not the audience that needs the commit mail explain to them.
They've already stepped aside of this.
And so, few people can take this on, like, very directly.
I think it would be great if there was regular news about free BSD development.
As a project, we do quite well in documentation,
our managers, I think are better than anywhere else.
I've struggled to think of a man-page average,
wasn't the free BSD one that I really liked.
But, you know, I'd like the man-pages.
The handbook's pretty good.
We've got reasonable tutorial stuff online,
but we don't talk about what we do.
We're really poor at communicating what's going on.
Yeah, so in the last few years,
there's been some efforts towards this.
Mike Carles was helping with release notes,
and he was assembling more stuff.
And it was doing well.
Very slightly passed away last year.
We've been doing status reports,
but I've read all of the status reports and they're very hard to digest.
And they're not immediately tied to things.
And I don't see coverage of them.
I don't see anyone care.
And for other things you do see people care.
And I had this idea a long time ago that,
you know, LWN exists.
LWN is an amazing thing.
And if you want to talk about advocacy for an open source project,
LWN is just above.
They write really high quality technical documentation
based on active development.
It's, for a long time when I was an academic,
it was a first stop before reading a paper
because there'd be a paper a conference for some change.
LWN would give you an approachable explainer for what was going on.
And they're really great for documentation like that.
And they can do this because they have money.
LWN costs money to read every month,
but some big companies pay for open source maintainers to get it.
But they pay their staff.
They're paying writers.
They're paying probably a staff pool of 20 to 30 people.
And they may have 8 to 10 contributors for each issue of LWN.
And so there's money here.
And you know, we're a smaller project.
We don't have this big kishae.
We don't have as much going on.
We're definitely not enough activity to keep 10 people
contributing freelance articles.
And I would see if we could make a semi automated approach
to summarizing development and frivolousity.
Can we break down the problem a bit
and get a technical writer?
So a technical person,
but not a subject matter expert.
To ingest this fire hose commit log,
speak to people and give us something useful on the other side.
Can we reduce the expert burden on the knowledge?
So you can communicate what we're debating on our projects better.
And I want there to be more writing about frivolousity.
I've been doing this for a very long time now,
which is kind of sad to say.
I think I came to close them for 10 nine years ago.
Since then, I've written a ton of several papers
where I never managed to anything really focused on frivolousity
because I worked in networking.
But you know, we very frequently use frivolousity as a platform.
And we get to, you know, in the paper,
you get to use a wonderful justification of why you pick this.
And you just get to say,
the authors knew it.
And that's why you did it.
So I got to push frivolousity into more places.
I did more frivolousity to the ITF.
I've written far too many presentations.
That's why I've just wrote a shell script
because of the sick of keynote.
And I put our writing in other places.
So I've kept the blog as too scared to see
when I first started writing about frivolousity
but it's probably a long time ago.
And I put out commercial articles, places you've read,
big magazines.
And I'm an editor in the frivolousity journal,
which is a magazine where the word journal
and the title to confuse academics into submitting,
which works really well.
And so I wanted to be more about frivolousity.
And twice a month for some reason,
it was Benedict Washington.
And we record BST now.
And we talk about BST.
And most of what we talk about is based on what other people have written.
And if you stop writing,
we don't have a podcast anymore.
And I'll get those hours of my life back.
And nobody wants that.
They want to keep the podcast going.
There's no place right now for what's going on in frivolousity.
There is a great place for what's going on in open BST.
Undeadly the org is an amazing resource.
It was a big draw to me as a nerdy teenager
wanting to just read more and not necessarily having
the technical tropes to do development.
I could read on Devly.org and I could see,
you know, the technical articles we'd go by.
And I didn't know how to pronounce WX or X,
let alone know what it meant.
But I could read about hackathons and how they
progressed the project.
And I could see ways in.
And that came from relatable writing about the projects.
And the things that are happening.
So we need more of this.
And we need some way through.
I did this off my own back.
I'm a staff software engineer at FreeBestie Foundation
to give me latitude just to do stuff.
And so I just did stuff.
And I thought I'd be fun to write some shell scripts
because shell scripts are just the best thing in the world.
Put out some reports because if you ask for opinions,
you're just going to get mired and locked down in
what other people want from something.
They will dream the biggest thing in the world.
And that will slow down the momentum here and I will stop things.
And we'll push this out somewhere really easy.
So I put it on my blog, which is the easiest place I could
put anything, which is also a tangle of shell scripts,
which is just perfect.
And then through some growth hacking techniques,
solicit feedback from the community about what's
good, what's bad, where things should go.
So I wrote a shell script.
You've now seen the shell script.
It's very simple.
It generates a list of commits to review.
It uses the magic of Gitlog to do commits from
last week until now, which anyone who's seen
enough by one hour is like, you're going to miss stuff there.
If you don't do this exactly the same time, it doesn't matter.
If I miss stuff, that's fine.
It shouldn't slow down the momentum.
We want to get stuff out and we don't want to get locked behind
the barrier of perfection because that will just stop
as doing things.
And it's much better to have anything in the world than
nothing in the world, but it'd be really, really good
it's just on your computer.
I made an interface to go through the commit so I could
take them and reject them.
It's one shot.
So if I hit enter too quickly, I get a commit, which is
fine.
I'm a human.
I'll just remove it later.
And if I hit no, it's gone.
I don't cover it.
Hopefully, it was in a series that I will catch.
Or someone will tell me I missed it.
And I can go back and talk about it.
It keeps the log of the items that we're going to be
to buck it.
But that's just so that I could make a plot like I did
at the start here.
So I can think about trends in the future with
some supporting numbers.
I didn't know before starting with how many commits
there would be in a week or three BSD.
I'll let alone a year.
And so that was good.
I templated the final report.
Templating the report gives you something repeatable.
And all I mean, English gives you like a nicer, consistent document.
And consistency is a real benefit for anything because it
helps the reader.
For a technical material of the reader knows what to expect
next.
They won't be surprised.
They'll know how to skip through the boring stuff they don't want.
But they'll also know the cues in the writing that will help them read.
It's a really good way to get better understanding from something.
So each Friday, I was streaming this, but it proved too hard.
Did you get pool and I run a shell script.
And then do some other stuff.
I was streaming this, but it conflicted with having a six month old.
And while I can write a report, I can't write a report and talk about it
without sounding like an absolutely crazy person.
When I've had no more than two hours sleep at a time for three weeks.
So I had to put that away.
Maybe we'll try again in the future.
The report generates a file with a header.
The header consists of going on in FreeBSD because I like the English turner phrase.
I don't know how well this translates outside of English.
It has a file I keep just in the director for this called Notes,
where I've assembled stuff that isn't going to appear in the commit log.
So good example of this is the stab.
The stabilization we remind us that the lab has been running,
where they pool part of the FreeBSD tree and they try and just test it in production
for Netflix and other places.
And they land in the FreeBSD source mailing list, but they're not commit,
so they don't appear and get.
So they just sort of disappear.
I've put the section headers.
So I remember what the section headers are called.
So when you read this, you can look in the section you looked in before.
If you want to know what happened in wireless.
And it puts a fruit in.
And the fruit has two things.
It says, please send me an email now.
I want to know this is good.
And it thanks the FreeBSD Foundation for giving me the time to do this.
I get this log and I get a list of 20 to a couple hundred commits for this one time.
And I have to rearrange it into logical groups that would make sense to discuss
and make sense for a reader to understand.
I've not been trimming out some of the stuff which is just going to fall in the bucket of some boxes.
Big, some bug fixes updates and improvements because it's a bit tedious, but it's also good to see.
By rearranging these, the order gets thrown away.
But if you want to know the order things happen, you have to get logged.
You can just go pull this so I just don't worry about it.
And I had commentary as best as I can with the desire to do things quickly first and accurately second.
Because there's just nothing better in the world than saying something wrong to get the right answer.
I published the easiest place I can.
I published somewhere easy because I could publish them quickly.
And so it goes on my blog.
A part of it going on my blog means that nobody else has to check over this because it just goes out.
And you can't stop me blogging.
If it went out through the FreeBSD Foundation,
I think things would get a bit more mired.
They would probably want to have a run over.
And they would then, no, give me the freedom just to do this whenever I wanted to do it.
This just gives me the speed to get the right thing out there.
And then I solicit feedback.
So I sent emails to FreeBSD Net for BST Current.
Net because that's where net work and things happen.
Current because that's where people should be reading if they care about what's going on in current.
I put on the Fediverse.
I drop it into places that will not complain if I put my blog frequently.
I think I've syndicated on some planets, but they're on now just all say FreeBSD network staffs report on them.
Which helps no one at all.
And yeah, I just try and get comments.
So I started doing this.
I think in September, 2024, it was week 39.
The week numbers are dictated by the date command with the V capital V flag.
If you have an argument, you can argue with ISO rather than me.
I don't mind.
I did 12 through the end of 2024.
I stopped on week 50 because we were traveling for the winter break.
And so I wasn't going to have time to sit down and read a ton of stuff.
I picked them up again.
The third week of January.
And I did a mega catch up report in between which covered just under 800 commits.
And it was horrible.
It seemed like four hours to digest all of these.
I could feel myself getting tired right in this just going.
It just just fixes.
It doesn't mean anything.
And so I could see what would happen if you tried someone else tried this.
You didn't have any knowledge or intuition about how stuff works in FreeBSD.
I had done two more reports.
I did one yesterday.
I thought it was good.
I've had some great outcomes from this.
You should buy Kristoffa Beer.
He's left.
So.
I'm going to beer.
You should buy him a beer.
Kristoff is consistently committing a series of improvements to PF, which is I find a standing.
It's funded by NACA and you can see this continuous work going into improving this
firewall.
It's really good.
I've gone a lot of positive feedback.
I've asked for feedback.
And this really helped Caleb Sasser the CEO of panic ink.
They make max software.
You have a talk at the last XOXO conference last year where one of those messages from
this was send a nice email.
If you see someone doing something you appreciate or you want to happen again or has helped you,
you should just thank them.
It's, you know, four words.
Like, like, thanks for that post.
And that helps wonders.
Most of us are saying a home by ourselves and we never really speak to anyone.
And we get bugs.
But just putting out some positive feedback to the world makes everything much better.
Because you can't come to a conference every week.
But you can't just get an email from someone who's gotten some benefit from this
stuff you do.
I've gotten a real strong sense of what's going on in the 3BSD project from doing this.
And, you know, I said that 3BSD commuters get source emails.
I read them.
Sometimes I didn't read them for six months at a time.
But I've read them, like, cursorily, like, not particularly in depth.
Not reading them in depth because I have to categorize them and getting a lot of value from this just to know what's happening.
And hopefully I'm just doing that out.
I learned about the internal driver modernization that Kevin Bowling was doing,
which I think I would have missed.
I would have been like, it's just some numbers that skip that.
But now I get to refer people to talk, you know,
people with bugs.
I can say, well, you could try 3BSD current because it has the new things in it.
You should try and do that.
I've got a great sense for the continual work that goes into the 3BSD TCP stack.
And I sit on the 3BSD transport call every two weeks.
I should know what's going on.
But actually I've got a much better idea of just the small changes that are going through.
I've got a great sense of the small changes which are constantly going into the TCP stack,
because it's working on really complex code.
I learned a much better idea of how many changes to 3BSD are just continuous stuff.
There are a bunch of commitments who are just fixing typos, which seems, you know,
not the highest value work.
But actually, it's increasing the code quality.
They're going through in their reading things.
So we actually get to know the code has been read.
If somebody comes in ads or removes an apostrophe somewhere,
that has been looked at in the last 10 years.
And for a large part of our code base, it's four years old and no one's looked at it.
Sometimes.
But they also find small changes and fixes and it's just this constant cycle.
We don't get, you know, four major releases a year the way the Linux kernel does,
where you have to figure out what all the features are.
We don't see stuff coming as much necessarily because no one is doing media coverage on fabricator
and stuff coming in.
I don't think the Fruity developers would want media coverage on stuff in fabricator
in the way they do in the Linux kernel.
But we get to see the, you know, from looking at this,
you get to see the continuous work that goes through and how much better things get.
You know, BF is dying is a very old meme now.
But it's definitely not dying if you look at the commit log.
It's just continually moving forwards.
Doing the selection process to bucket things into networking or I don't care.
Highlight at a ton of stuff.
I really cared about which wasn't networking.
So that, um, truncated post by Kirk, where, you know,
he's doing a fix for UFS one file systems.
So the date stamps will work in 2038, which is Kirk's, um,
84th birthday, right, a card now.
Um, and I don't know if I would necessarily have seen that,
I would even like that to a big commit message move on.
But instead I read it, and it's really nice just to see that come through.
There's, there's great value there.
So I said I wanted to be more free BSD content.
There's a podcast to fill.
Ari needs release notes.
So people need to write more stuff.
And so I want to ask everyone here to write more.
You should just write like anything.
The scale doesn't matter.
It maybe needs to be more than one sentence to have value,
but it might be a really funny sentence.
Like you might really hit the mark there.
You should write where you can first.
And we can figure out other places for you to write in the future.
Um, I'm on the editor of the free BSD journal,
which is a magazine about free BSD.
And we, we moved to quarterly, but we're always after
contributors.
And we want new contributors as much as we want continuing contributors.
Because it's quite a burden.
We ask for people to write, you know, reasonably long technical articles.
Um, but yeah, if you want to write more and you don't have a venue,
I'll help you find one.
Sign up at blog easy, but I can also help you with that.
You can also write for the foundation.
I don't think there's any organization in the world,
which should say they've got too many good technical writers.
Most places say it's impossible to find a technical writer who can deliver stuff.
And so you should write stuff to get to the point where you could be a good technical writer.
It'll make everything you do better.
And you should write for other places.
Uh, I spoke to the journalists from a friend to the next magazine today,
which I didn't know existed.
How cool is that?
So you need to write for other places.
And there is.
Um, the VPP work I did, which was funded by Arginance in the free BSD foundation,
we pushed really hard to get into as many venues as possible.
And this led to someone a conference in December saying to me,
I know your name because of the VPP work.
They did not have any context for free BSD,
but we got the word out of there.
And we spread a lot more awareness about the project.
That's all I have.
Thank you very much for listening.
Please go write stuff.
Thank you.
Five minutes.
Just a comment.
I listen to this.
I think we, and in that BSD, we should do a lot more of this.
Because I feel like we're suffering from lower mind shared and say free BSD.
And part of this is that nobody writes.
Yeah.
So the comment was, in that BSD, we should do more of this.
We're suffering from lower mind shared than other projects.
And I think you're right.
On deadly.org is, and the artwork are the best bits of advertising in the BSD world.
And it's got this massive cliché.
Well, outside of his user's base, compared to free BSD.
And it's because they are frank about what they do.
There are bit means people and they have great artwork.
And they do really well just stimulating interest.
Yeah.
Well, the songs have been cringed.
I know your name from your BSD working.
Right.
And I refer to the voice.
Okay.
Thank you.