This is partially because the Linux kernel doesn't lend itself to layering in the kernel context, and there are some contentious topics that take a long time to hash out upstream, like https://lwn.net/Articles/764461/ ….
-
-
Yeah, makes total sense. Carrying Linux kernel patches is basically expected :)
1 reply 0 retweets 0 likes -
Replying to @aronchick @julsimon and
True, but working upstream is also expected—unless you are ok getting *way* behind due to upstream velocity. Not faulting Google for carrying kernel patches (we do as well, for our general purpose datacenter kernel and the purpose-built kernel at the core of the Nitro hypervisor)
2 replies 0 retweets 1 like -
Well that's the interesting bit. Lots of folks want to and have been contributing upstream, but there are examples of those changes not being inline with the general architecture the community wants. That's fine! But if that's what YOU want, welcome to patchtown.
1 reply 0 retweets 1 like -
Replying to @aronchick @julsimon and
Linux kernel development scales remarkably well considering the size of the project and the number of contributors. A lot of credit goes to the modular architecture and subsystem maintainer model. But when you want to get into core code like the scheduler and mm subsystems...
1 reply 0 retweets 0 likes -
Replying to @_msw_ @aronchick and
But, going back to "At Google, for example, we worked really hard never to fork for private versions just to manage scale" Except when you did, like for the internal Linux kernel. Or any of a number of other forks for both reasonable reasons and befuddling reasons.
2 replies 0 retweets 0 likes -
Agreed, but then I don't believe we ever publicly release those forked versions with new names and do press tours about them.
1 reply 0 retweets 1 like -
Replying to @aronchick @julsimon and
Right. I can understand some confusion there, since Neo-AI is somewhat like a distribution / collaboration that makes use of some existing things. How would you do the naming? I'm really, really, REALLY bad at naming.
2 replies 0 retweets 0 likes -
Replying to @_msw_ @aronchick
I will put forward a few Google forks for consideration: BoringSSL (fork of OpenSSL, and also very awesome) JanusGraph (fork of Titan) Android (containing a fork of the Linux kernel, and a lot more) And, not a rename, but https://opensource.google.com/projects/collectd-netperf … why not get that stuff upstream?
3 replies 0 retweets 1 like -
Replying to @_msw_ @aronchick
JanusGraph is not a Google fork; it's a community project under The
@LinuxFoundation, with many equal participants, including an Amazon rep on the Technical Steering Committee, and Amazon signed The@LinuxFoundation CCLA to contribute to JanusGraph, and does. All good.2 replies 0 retweets 0 likes
Indeed, I didn't mean to imply that there was something otherwise. I was trying to say something different: often forks are healthy and normal, and I think that JanusGraph is a great example of the resiliency of open source.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.