Hacker News Reader

Comment by jacquesm | Hacker News Reader

I'm fine with that. Github is 'too large to fail' already, adding the Linux kernel to the pile and forcing the kernel team into Github's workflow are two big negatives. It would be great for Github but bad for everybody else.

View on HN

Seriously. Linux will likely outlive GH[1], and more importantly, it doesn't need GH. The current workflow works fine, and I hardly think any potential kernel hackers are choosing not to work on the kernel because it is email-driven.

[1] Nothing against them that I don't have with any other commons that depends on corporate beneficence. But companies fail all the time; I can't think of a reason GH is immune.

It's not like open source projects are immortal. Some die due to poor management, lost developer interest, lost funding, or some fork becoming more popular. Or all of the above.

For me Linux is the core of the open source movement. If it dies the rest of it might die with it.

Wow. That's bleak. Linux will not last forever, irrespective of how it might change.

Change is gonna come someday. Don't get left behind because of sentiment. This isn't a judgment on the Linux project, this is reality.

Linux will likely outlive all of us. Network effects are massively strong for operating systems, we've been stuck with the same basic 3 for decades and that's likely to stay the same.

Only if you consider servers.

Mobile operating systems such as IOS have become huge and they're many new industries that look promising (my guess is IOT based one like alexa and Google home but who knows).

There are two major mobile operating systems, iOS and Android, both based on Unix clones, one on BSD and one on Linux. Mobile has dramatically increased Linux usage; what do you think Android is?

You bring up valid points.

However, ios makes most of the mobile profit just as windows and Mac do over Linux for desktop (I have only used Linux in server industry so I don't know how they fair in those markets too much).

In that light, How about this prediction.

Linux will continue to dominate in the server market for a long time as businesses factor in the cost of os licenses and the supply of linux users is big.

Consumer markets like desktop, mobile, whatevers next will flock to the lower personal cost (through customer time investment in learning the os).

Agree, thus Linux will live a long time.

If Linux dies, it will either be because something better emerged to replace it (yay!) or the civilization necessary to support it imploded (boo!)

Well, it might happen that Google will fork Linux into their own thing, and it will be harder better faster stronger, and for some reason hard to merge back into Linux. And the ecosystem will move.

It's hard to imagine now, but it can happen.

Or it will be GNU Hurd.

(Ir)relevant xkcd.

https://xkcd.com/1508/

> The current workflow works fine, and I hardly think any potential kernel hackers are choosing not to work on the kernel because it is email-driven.

I'm not so sure. If the kernel development was on Github, I may have looked into contributing, but as it stands, its not worth the trouble to try to contribute (as I don't have anything specific to help with). And, I suspect there are more capable developers who are closer to the edge than me.

Anyway, having a slightly lower bar to get started may not get more developers involved, but instead my get them involved more quickly.

Linux is one of the few open source projects to with plenty of developers. They don't need or even want your help, especially if your attitude toward tools is rigid, and if you have nothing concrete to contribute.

Linus has said this a few times -- in general they don't actively try to onboard new contributors.

"They don't need or even want your help"

There was in fact a talk given by Greg Kroah-Hartman, one Linux's lead maintainers, about development for the Linux kernel which he titled "I Don't Want Your Code".

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

Haha, thanks for the video. I watched it, and I was surprised to see that it's about a specific company.

He's at Linaro, specfically taking their developers to task for sending bad patches. And they indeed sound horrible, but he's good natured about it.

I'm just starting to accept patches for my project, and honestly I'm flabberghasted that people will send patches that not only don't run, but don't build. And Greg was saying the same thing.

I guess I got spoiled at my last job, where people generally sent high quality patches / code reviews. Although toward the end, I noticed some sloppiness. It wasn't the main reason I left the company, but it started to feel like the downfall... I don't want to work with people who don't know how to submit code reviews / patches.

Linaro isn't a company; it's a "collaborative engineering organization". It does employ some number of engineers, funded by donations by their member companies, but they also accept "in-kind" donations where engineers are detailed to work at Linaro for some period of time. So it wasn't really directed at Linaro per se, but more at the member companies of Linaro.

> I'm just starting to accept patches for my project, and honestly I'm flabberghasted that people will send patches that not only don't run, but don't build. And Greg was saying the same thing.

Indeed, I've seen the same thing. I have considered automatically rejecting any patch made with the GitHub online editor (obvious because the committer name is always GitHub). They are pretty much invariably of shit quality.

That's fair enough. The only times I've submitted patches that way is to update documentation files. I'd never submit code that way.

So, what's the age distribution of contributors to the main tree, and how does it develop over time?

This _might_ show a long-term risk for Linux.

80% of the kernel development is done by companies who want their code in the kernel (whether that's because they develop hardware or because that's less work than maintaining their own patchset).

It is important to understand development for Linux is heavily driven by a business need. There are more than enough companies (intel, google, etc) that would gladly contribute to Linux, since it makes business sense.

Kernel development shouldn't have a low bar, it should have a very very high one. Anyone that finds email a high bar for communication doesn't belong in Kernel development.

This is gate keeping at its finest. Email is a clunky tool to do development with compared with what is available. A persons willingness to use email (and all the quirks for submitting a patch) for patching the kernel has nothing to do with the quality of code that they write.

So clunky! :D — With 2000 commits per day, I don't think they need more people. I can't even imagine trying to fit that amount of source code change into any management style, let alone one that has little or no gatekeeping. Making the barrier to entry higher is probably only one step to prevent the project from self-immolation.

So they're gating developers by their appreciation of the chosen toolset? Wouldn't you rather see them challenged on their programming abilities? Do you suggest a correlation, I find it hard to believe there is one?

>So they're gating developers by their appreciation of the chosen toolset? Wouldn't you rather see them challenged on their programming abilities?

No, the former is enough. It shows that whatever their programming abilities they are prone to bike-shedding, so they are better avoided.

Well they are doing both of course, your patch will still get rejected if it's bad, even if you were able to figure out where and how to send it. But it reduces the amount of patches that need to be read and rejected.

Also we are arguing backwards here. They don't make it intentionally hard to keep out new contributors, it's just not important in any way to make it simpler. The goal is to make it work best for the thousands of existing contributors, especially the gatekeeping subsystem maintainers.

>Also we are arguing backwards here. They don't make it intentionally hard to keep out new contributors, it's just not important in any way to make it simpler.

Generally yes, but IIRC Linus has explicitly said that he likes the process being intentionally hard to keep out new contributors.

It's the Kernel, the gates need to be kept else fools mess things up, thank god for Linus.

Some things need to be gatekept. (One obvious example is OS kernels.)

If you won't submit a kernel patch because you feel that email is unfashionable, then you're kind that should be kept out of the gate. Sorry.

> Email is a clunky tool to do development with compared with what is available.

The linked article explains at length why it works well for kernel maintainers. And since it does, why should kernel maintainers change it just to make things easier on newbies? It's much more reasonable to expect new participants to adapt to a workflow that works, than vice versa.

This is not "gatekeeping," it's just the reality that not everyone works the same way.

You can send a patch to a mailing list with `git send-email`. You can format it first with `git format-patch` and then send the patch with `git send-email`. Configuring it to use your email server takes a few minutes, and you only have to do it once.

I get the feeling most people who complain about how "clunky" email is have never actually tried to submit a patch to LKML. If I could figure it out when I was a high-school student, a professional developer should be able to figure it out as well.

>This is gate keeping at its finest.

That's as intended.

I wonder if the email list acts as a gateway to filter potential troublemakers and trolls. A troll denied their audience is a troll defeated.

The kernel lists get plenty of trolls regardless.

Launchpad has quite a bit of git support now.

Personally I'm a fan (and user) of gitlab since GitHub's recent policies and that GitHub takes forever to implement simple things that all users would love (like free private repos)

>GitHub takes forever to implement simple things that all users would love (like free private repos)

What makes you think Github is 'taking forever' to implement that feature, instead of refusing to implement it to help their business model?

I would like a free, private Aston Martin, but the manufacturer is taking for ever to implement that too.

But I take your point. This is why I drive a Nissan.

I'd say GitHub is not Aston Martin if GitLab is Nissan...

Well, my Nissan wasn't free either and I don't use GitLab at all.

So that's why it's a good idea to use bitbucket as well. Then you get the free private repos there.

Fuck yeah Bitbucket.

I was waiting for someone to mention that. Free Aston Martins!!!!

Why on earth would they want to provide free private repo's, that's something they charge for... ON PURPOSE. They aren't taking "forever", they're simply not going to do that.

Reply on news.ycombinator.com