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.
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.
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.
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.
> 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)
> 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.
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
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)
[ 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.
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.
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.
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.
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 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.
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.
Can't stop laughing evilly at the thought of him instead tearing into a 4-year-old like
Christ, Maisa, your reasoning is weak as hell, and then you come up with THIS shit. Heck no. In fact, not a fucking way in hell. Look yourself in the mirror, Maisa. This patch is ugly, and then you have the gall to quote the "the last s is sad" thing in commit... compared to the diseased abortion you just posted...
EDIT: Shoot I keep having to edit to add more virtue signalling. This is wrong, do not do this to children. Hopefully you didn't need to be told that. Also, Linus is trying harder now. But this is a joke. Someone will make it. It's funny because it's wrong. (Nothing is less funny than when exactly what's supposed to happen, happens.) But Linus did totally say this to someone; I just changed the name.
Nothing. The person above does not realize that Linus doesn't yell like this at newbie committers. His rants are directed at people who -should- know better.
I'm not justifying them, but there is quite a difference.
See my sibling comment to yours. The outrageousness and unlikeliness of yelling at a 4-year-old (the noobiest of noobs) is exactly why I found it funny in the first place.
Apparently I'm the only one who thinks it is, so I'll volunteer that I found it funny because it's unexpected and shocking, yet almost plausible enough to be believed, given Linus Torvalds' track record as a sometime verbal abuser of adults. Speaking of which, I just realized it also includes an unintentional satirical subtext that highlights the difference between how Linus most likely treats children (probably not like this) and how he demonstrably has treated adults (exactly like this). Which isn't "funny" per se, but there's your explanation. Explanations are rarely funny either, nor do they generally result in suddenly getting the joke and laughing. But I suspect that wasn't your aim anyway.
> 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.
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.
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.
> 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.
“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.”
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).
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.
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.
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.
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
-------------------------------
+-------------------------------
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.
"The 's' is SAD!" looks like something that our POTUS could have written. It must be nice to realize that Trump is literally tweeting at the intellectual level of someone who is literally 4-year-old.
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.
reply