“The 's' is sad”: 4-year-old submits Linux kernel doc patch (2014) | Hacker News Reader

“The 's' is sad”: 4-year-old submits Linux kernel doc patch (2014)

git.kernel.org

429 pointswolfgang42108 comments

Linus on trivial patches:

https://lkml.org/lkml/2004/12/20/255

[ Linux-kernel added back into the cc, because I actually think this is important. ]

On Tue, 21 Dec 2004, Jesper Juhl wrote:

> Should I just stop attemting to make these trivial cleanups/fixes/whatever patches? are they more noice than gain? am I being a pain to more skilled people on lkml or can you all live with my, sometimes quite ignorant, patches? I do try to learn from the feedback I get, and I like to think that my patches are gradually getting a bit better, but if I'm more of a bother than a help I might as well stop.

To me, the biggest thing with small patches is not necessarily the patch itself. I think that much more important than the patch is the fact that people get used to the notion that they can change the kernel - not just on an intellectual level ("I understand that the GPL means that I have the right to change my kernel"), but on a more practical level ("Hey, I did that small change").

And whether it ends up being the right thing or not, that's how everybody starts out. It's simply not possible to "get into" the kernel without starting out small, and making mistakes. So I very much encourage it...

So please don't stop. Yes, those trivial patches _are_ a bother. Damn, they are _horrible_. But at the same time, the devil is in the detail, and they are needed in the long run. Both the patches themselves, and the people that grew up on them.

I really hope that next time when somebody tries to paint Linus as an asshole and a toxic force for the community because of his rants, someone remembers to link this email too.

It demonstrates how Linus is not only a good programmer, but also a good leader.

I get the same idea as with the first Gordon Ramsey Kitchen-fixing programmes. Apparently, people said it was insane how he dared to swear on TV. But basically, he notices things are very wrong, makes sure he gets to the bottom of the mess, and hammers the ugly message very publicly into some owner who lost any connection with reality. If the cost is some swearing, that's the least of the problem. The failing businesses get fixed at least as much on a sociological level as on a cooking level.

Linus does the same. A big software project's problems are more sociological than technical in nature. Sometimes, the ugly message has to get trough, an another famous rant is born. But most of the time, work gets done, probably with a reasonable amount of smiles.

The US Kitchen Nightmares are completely faked up drama for US audiences. Watch some of the original UK ones and you’ll see how he tries to coach the chefs with comparatively minimal swearing and anger.

I am indeed mostly talking about the UK versions. The US versions had much more drama and much less cooking, but underlying it had the same theme.

Unrelated to the article, but the early British seasons of Kitchen Nightmares were so good.

I still enjoy watching the Fox version (and his new show, 24 Hours), but I appreciate those original seasons much more.

You might like The British Baking Show on Netflix. No yelling, everyone is super supportive of each other.

It's definitely near the top of my list! And may be higher after your comment. :)

Mitchell & Webb's take on Kitchen Nightmares, more criticism than comedy

https://www.youtube.com/watch?v=i1NfWIaYed8

You don't have to be an asshole all the time to be an asshole.

I also like this email where he explained to a CS student the difference between spinlocks and semaphores.

https://yarchive.net/comp/linux/semaphores.html

Someone can be an asshole and a great leader, at the same or different times. Linus himself, to his credit, recently admitted that he's been unreasonably abusive and is trying to learn better.[0]

People are complicated. He needn't be either a saint or a demon.

[0] https://lkml.org/lkml/2018/9/16/167

that he's been unreasonably abusive

I have not heard of Linus taking credit for other people's work, or him getting into a fistfight at a conference or feeling up women's asses.

And apples are not oranges, but they are both fruit.

Good thing no one implied any of that, then!

The thing is, all Linus rants that I've seen are entirely reasonable. Yes, calling someone stupid is rude, but rude things should be used in extreme circumstances. And when a single developer can negatively affect millions - wait, actually, billions - of people around the world with a stupid patch, that's exactly the case where being rude and aggressive is entirely reasonable.

Being rude and aggressive would be reasonable if there was some imminent danger, but there isn't - he can calmly explain things and doesn't have to merge anything until he's ready.

> all Linus rants that I've seen are entirely reasonable

Spot on. I'd hate to be on the receiving side, but look at what we've all gotten from this effort - in a Machiavellian sense it really has been the correct choice.

If you cuss and scream at someone, and they subsequently do what you wanted, it does not follow that they only did that because you cussed at them.

Linus himself appears to disagree with you, now. You don't need to defend him.

Linus admitted himself that his behavior was sometimes out of line. That doesn't mean he was always "an asshole", just that sometimes he was. He has accepted that and worked to change it.

Stop trying to paint progress as a bad thing.

Just because someone is frequently an asshole doesn't mean they're an asshole 100% of the time.

Well, serial killers don't kill almost all the time also. Reminds me of that Monty Python sketch where the army guy tries to reassure the interviewer by saying there's "almost no cannibalism in the British Army."

This is such a great comment and very true. Looking at the speed and attitude that maintainers handle trivial PRs with can act as an indicator of the project health and will definitely make it more inviting for new contributors!

In my experience, you can read a (large) code base all you want, but until you get in there and start making (breaking) changes, you're not truly going to understand it.

I think Linus's quote largely reflects my opinion/experience. A new comer's changes won't always be good or right, but get in there and try things out!

I have been trying to get into that with not much success. It looks like I end up trying to understand the whole thing at once. I don't know how to look at the source code which solves a specific small problem. Is there proper guide by earlier contributors about how to get used to the source and start breaking/fixing things?

I remember my first few commits to big projects were documentation ones. Like —inspect documentation in nodejs, and node —help.

It gives you exposure to code, the dev loop, general idea of how things work. Then one can take on bigger and bigger challenges.

We all gotta start somewhere.

I am a bit sad that Linus is more known for his occasional frank outbursts than for his consistent encouragement and supportive tone.

Ngl, that's what I know him for the most.

I agree on the general concept of your post, however I cannot observe, at least for the things I maintain, that there is this pattern of "people starting small". At least not small in the sense of trivial changes. They maybe start submitting a small PR but that is most of the times already at the level of the contribution that they'll make in the future. So people that will become core contributors will send a small PR with a core change, showing already that they can understand the core of the system. However the open source movement cannot only optimize for the raw code output. The "I changed this" feeling is also great for users to realize that there is space for everybody.

Perhaps there is a community-wide phenomenon of progression, but not observable within single projects?

I wonder if this may be similar to the "won't hire jr. developers" tragedy of the commons that many companies are party to: the economy as a whole would benefit from investing in jr. developers (by providing an environment in which they can advance to sr. developers), but for each company individually, there is risk in training someone up in a year or two only to have them leave and become a "mid-level developer" at another company.

Here's my first PR to Rust: https://github.com/rust-lang/rust/pull/4305

Note that it was rejected because I sent it into the wrong branch (we do use master these days) and so I even had to resubmit it https://github.com/rust-lang/rust/pull/4308

I'm about to send in my 972nd PR now. The Rust book is 520 pages; that was the second version, the first of which was ~300 pages. Quite a big difference from +34/-2. I'm at +142,087/-166,524 lines to the main repo now, and #12 overall contributor.

Yes, not everyone who sends in a small patch will become a core contributor. But some will. It's a numbers game.

This is a great real world example. However I would rate your first PR as very good... Documentation improvement, with examples, is something which is very hard to get. Btw in general, I totally agree with the basic idea of trying to merge trivial patches. I go a step forward and I merge "just typos" PRs even if they have the bad effect of breaking other very important PRs sometimes, because a trivial break will be a trivial rebase anyway and typos cannot stay there forever.

From this POV btw Github does a terrible job not telling maintainers: "merging this PR will result in the following PRs being no longer mergeable". Most of the times the list would be empty, making the merging of small PRs a lot more a non brainer.

Linus says:

> I think the trivial patches are among the most important ones - exactly because they are the "entry" patches for every new developer.

I have been running a fairly successful open source project and this is not exactly my experience. I guess about 70% of pull request I get is simple spell, grammar, white spaces and the likes. Some time folks send this in wholesale because they want their personal favorite verbiage. It takes enormous amount of time to go through each line and each file to make sure something else is not sipping in. However, more importantly, rarely I have seen these text fixers to send any real code fixes. Vast majority of them are just one offs.

My thesis is that there are lots of folks out there just trying to brag to be "contributor" for popular open source projects and they just move on from one project to next rarely taking time to settle down in any individual project. This might be not be the case for Linux kernel but might be the case for other smaller projects.

A more generous interpretation (and the one that I think explains my very short stints as a contributor in just the way you describe) is that I really appreciate the project, want to help somehow, but won't/can't commit to deep work on the project. I also see many projects that practically beg for help "even if it's just documentation" and believe small contributions to be similar to adding a dollar to the tip jar.

> takes enormous amount of time to go through each line and each file

>My thesis is that there are lots of folks out there just trying to brag to be "contributor" for popular open source projects

Do you have an example of this? All I could find in your top 3 repos was one pull request updating the readme and its only 8 lines.

https://github.com/sytelus/CryptoJS/pull/3/files

To be fair, he works for Microsoft, its entirely possible he maintains one of their OS repos.

>It takes enormous amount of time to go through each line and each file to make sure something else is not sipping in.

This is an enormous exaggeration.

I've done this for a few projects, and it's almost always a PR to fix a specific pain point that I've had, that isn't obvious from the PR itself. Examples are

- downcasing some http headers in an example (because they wouldn't match unless downcased, which I spent hours figuring out)

- replacing a regex search with a string search (because it made the method 30x faster and it was on the critical path of a weird edge case)

- allowing the user to prevent some harmless automatic stats being loaded in a postgres library on connect (because it broke cockroachdb, which uses the same wire protocol)

- quoting the urls in some generated CSS (because in base64 "//" is sometimes a valid encoding and our CSS preprocessor implemented line comments)

Now, I left a description for all of these that explained the problem, but without context they'd just look like I was collecting "contributor" labels.

The only time I've really seen this has been in October, when DO and GH ran their "Hacktoberfest" promotion. Open 5 PRs during October to get a free T-shirt, and some people really just pick random repositories and send random tiny changes. I really liked Hacktoberfest in the past, but this year these people really soured it to me.

E.g. look at 22-52 days old denied PRs on the HTML spec: https://github.com/whatwg/html/pulls?q=is%3Apr+is%3Aclosed

That's an entirely different thing to "serious" small fixes that actually clean up small problems in docs and such.

Not my experience at all. And even if true, it wouldn't matter. Someone found a problem.

They can

a) ignore it

b) file a bug/shout on irc

c) do a pull request.

I much prefer c over b, and both over a. Every little bit helps, and it's improving the current state. I've hardly seen people doing extensive (as in hard to review) commits that looked like busywork to get an 'I commited' badge of honor (is that a thing?) in any repo.

And I also do that all the time, if I find some thing that's quicker to fix via PR than even find the external bug tracker or the irc channel? Everybody wins.

Mailing list thread: https://lkml.org/lkml/2014/11/24/407

  > When I was reading the documentation, my 4-year-old
  > niece wanted to see what I was doing. After telling her,
  > she noticed that something was very wrong and asked
  > me to fix it. Instead, I helped her fix it herself.

Sounds totally plausible. I never cease to be amazed by my 4-year-old's attention to detail. He notices everything.

Everything they do is the first time while grownups have done it dozens of time.

Well, now a 4-year-old has one more kernel patch than I have...

There's nothing stopping you, except finding the time.

One of the things I'm most proud of as a dev is a tiny contribution to the Nim standard library. It's a single commit and very simple, but made the PostgreSQL adapter consistent with the other RBDMSs' adapters. At the time, I'd been using Nim for only a couple of days, but that didn't stop me from being able to contribute in a meaningful way.

I'm amused and humbled that despite all of the work I've done over the past decade, it's quite likely that a seven-line change that I did mostly in ignorance will be the thing that impacts the most people going forward.

Here's the change, if you're curious: https://github.com/nim-lang/Nim/pull/6381/commits/921cc53e40...

> There's nothing stopping you, except the one thing that stops a lot of people

FTFY. There's a non-zero amount of time investment required to submit kernel patches (learning enough git, using the mailinglist, responding to questions, submitting revisions, etc)

Feel the same way about my contribution to the Go language. :)

Good catch there. Looks like you fixed one of those things that I'd waste hours on not realizing is the issue.

> I'm amused and humbled that despite all of the work I've done over the past decade, it's quite likely that a seven-line change that I did mostly in ignorance will be the thing that impacts the most people going forward.

My most popular open source project, by the numbers, is a ~40 line Rack middleware I wrote when jetlagged at 2am. ~29MM downloads all-time, 984 github stars.

I think about that all the time.

She should be eight by now, if that makes you feel any better... ;)

(Sadly, at age 53, I probably cannot get away with trying to make letters happy or otherwise be "cute", or I might well be inspired to try to do some kernel dev in the near future.)

Here's one you can submit, from the same file near the top in the ToC. It's missing two spaces after the header number. This line is sad because the lines above it and below it are able to stay lined up, but this line looks out of place. Being different may be a good thing for people, but it is not a good thing when you are talking about alignment in the Table of Contents.

  ---1.9 Ext4 file system parameters

  +++1.9   Ext4 file system parameters

So typical of Linux kernel code quality: The commit message refers to a missing '=' but the commit actually fixes a missing '-'.

;-)

I kept wondering where to find the change. I didn't initially realize it is apparently included. But this seems to be it here (from the bottom of the page):

   1.9 Ext4 file system parameters
  -------------------------------
  +-------------------------------

Yes, I was also confused looking for one of "those things [=]". I guess it was actually one of these things [-]. :D

For the love of god I still don't see an 's' with a missing (or newly inserted) "=". I've spent way too much time looking at this

There is a - missing under the s of parameters.

it's slightly confusing, because in the change the first dash on the first line is a "minus", indicating that line was removed, not part of the line of dashes. the line of dashes had one dash added to the end of it. (and it was a dash missing, not an equal)

       1.9 Ext4 file system parameters
    [-]------------------------------
    [+]-------------------------------

I've submitted many such small corrections to OpenBSD to help keep that standard high. No one will place those contributions on the same level as real development but I like that I've helped. And I know I appreciate it when even the documentation is kept at the same bar.

One of the reasons I fell in love with OpenBSD was the commitment to correctness throughout the entire system. This is a lot harder with Linux because they only control the kernel and not the entire distribution.

Please keep doing that. I'm still hesitant to contribute to tech@ with code and have yet to find a fixable issue in the man pages/FAQ in my own usage. But I do appreciate that the details are oh so right very often.

This uncannily reminds me of how I first learned to program (at ~10 years old, not 4, sadly).

Growing up, at my grandparents house, we had a communal old Mac (running OS 7 or 8, and BeOS for a while). Being a curious kid, I would often watch my uncle play Civilization II, and I would play myself. One day, I went to observe what he was playing, and instead it was programing in FutureBASIC. It sparked my interest, and he taught me the basics. This became a lifelong hobby, and I went from learning FutureBASIC from him, to then discovering a whole world of information online, learning REALBasic and PHP next, and C, Objective-C, and more. As a teenager, I made Mac apps and websites, and eventually when the iPhone came out, mobile apps. This gave me disposable income in high school (from selling shareware) and funded my one-way ticket and move to Silicon Valley.

A simple gesture like that, that sparks the right interest, can give someone an entirely different life and career.

The shareware era of the Mac was a magical time to be a teenage programmer. It’s one thing to get the validation of an adult’s approval, but something else entirely to have them pay you for something you built without knowing your age.

I bought shareware once 30 years ago and never got the promised unlock code in response. That stopped me paying individual strangers for software via mail.

Love this, but was a bit confused because the patch is 4 years old, a fact which which confirmed my initial misreading of the patch being 4 years old (rather than the correct reading that it was by a 4-year-old)

Interesting. I wonder if Maisa has gone on to write any more patches yet!

Or if she got corrupted by the dark side and works for FB now!

FB employees submit loads of interesting kernel patches.

They do indeed! The current state of the open source community owes quite a bit to for-profit companies working on the code.

Wonderful story :)

From date in mail list (https://lkml.org/lkml/2014/11/24/407) seems like [2014] should be appended.

Done! I didn't notice the date when I submitted the link, thanks for the suggestion.

Nice attention to detail! Perhaps, if you have some time later, you could read over the Linux kernel docs?

The best part about this story is that it is entirely plausible that a 4 year old found the problem, unlike a lot of stories where we are supposed to think there is a 6 year old wunderkind submitting code patches to some OSS project.

And here's how you get junior kernel devs :D

I hope you're still hacking on it and other projects, Maisa Roponen... Now 8 year old!

That is cute.

My coworkers thought I was making a sarcastic comment (apparently I have a reputation) when I suddenly said out loud "That is adorable!". I then had to explain what I was talking about.

Its almost tears in my eyes level. I didn’t expect to have that reaction.

When I listen to a beautiful piece of music it can bring a tear to my eye. I shed a tear when my grandmother died. I have emotions. But can you explain how the hell this could bring tears to your eyes? Frankly, I just don't believe you.

Well, maybe it’s because I have a young son and this reminded me of the innocent, magical realm of childhood.

Thank you for this model of how to respond to a comment that maybe was more insensitive than intended.

Yeah, I had the same reaction. I've noticed it whenever I see adults putting in an undue amount of effort 'just' to maintain a child's innocent expectation of a certain kind of universal justice.

It's so not a part of the adult lifestyle anymore that suddenly being confronted with it affects those sensitive to it deeply.

Christmas culture and thematics seems to target this dynamic.

I have a son who’s a small child so I see and encourage that magical world that we’ve all mostly forgotten about. Young childhood should be a human being’s respite from cold, hard reality. Of course, things don’t always go that way for children.

Having kids and supporting their interests is still part of adult culture.

It is! And a fun reminder that open source projects need help with more than just code, contributions to documentation are a huge help as well.

the difference between a community and a workplace is its tolerance, and need, for whimsy...

And here I am spending my afternoon tracking down a null reference error...

I like it. and as a bonus she can add kernel dev to her linkedin.

One has to be born with an eye for details... Well done!

I'm sure this was fun for the guy who submitted it but in the end just useless noise on the mailing list.

“So please don't stop. Yes, those trivial patches _are_ a bother. Damn, they are _horrible_. But at the same time, the devil is in the detail, and they are needed in the long run. Both the patches themselves, and the people that grew up on them.”

I'm sorry but there's no way the 4 year old learnt anything from this. Maybe the adult did, though. Is that the point?

She learned that her opinion is valued. She learned that it's ok to question things. She likely had a sense, based on the activity that followed, that she effected change in some way. I'm sure it was explained to her, and while of course she doesn't understand what a kernel or source code are, she surely had a sense of some positive accomplishment.

The world will become a better place if all kids get this golden treatment. I wish we could so easily push trivial changes to society but, in a very small way, this ripple in the ocean did.

"See this? We just need to change one little thing. There is a problem with the program and we can fix it: the president variable is orange. Let's work on that"

Exactly. My 3.5 year old could have noticed this (looks at my computer while I'm typing, and loves it somehow) and if they pointed it out I would have said "You're right! Let's fix it. Here you press that key. Great, we fixed it for us, but what about grandma? Should we fix it for her too?"

This would then lead to a kernel patch and they would feel incredibly happy about for as long as they remembered it (little kids love to help in any way).

And more importantly whole community learned from this.

She also learned that when you see something wrong, and you have the ability to fix it, it's a good thing to do so. Many big problems (speaking broadly here, not just about software engineering) really consist of such tiny things that aggregate, and can be tackled in a decentralized fashion if most people bothered to contribute just a little, even when it feels like the effort is minuscule and worthless.

Think of it as the equivalent of picking up a small piece of litter on the street, and throwing it into the nearby trash can.

I have a four year old. This patch was almost certainly submitted and entered by the parent.

Even 4 year olds comprehend much more than you seem to give them credit for. Do you think small children are somehow unable to understand things they are interested in if you explain to them on their level?

Maisa in this case probably learnt that there are grown-up text things like books on the computer, and it is a big thing if things do not line up and a letter is "sad". It is important to computers and people using computers.

And then to fix it for other people so that their "s" is not sad you write a letter with a computer and explain how they can fix it.

It might be interesting to hear her own memories of this, if she still remembers the episode.

Does anyone else have serious doubts about a 4 year old reading Linux kernel code?

Until a 4-year old can deal with the efficacy in which Linus communicates with other humans they should not be allowed to submit patches.

It takes some time to get used to Finnish style of management.

No worries -- based on their names, I'd say the girl and her uncle are Finnish as well. :)

Reply on news.ycombinator.com