Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 18:40 UTC (Wed) by cdibona (guest, #13739)
In reply to: Greg Kroah-Hartman: Android and the Linux kernel community by kragil
Parent article: Greg Kroah-Hartman: Android and the Linux kernel community

Forks aren't always great, but I honestly don't think of forks as being a bad thing and I've tried to instill in Google the same ethic.

In fact, I'd say that the various forks of Linux, and how the Linux maintainers have roped back in some forks (and let others go on their merry way) is what made the Linux kernel great and not just a BSD rehash.

Also, expecting to port Android to a new SoC to be super easy is unrealistic. I have nothing but admiration for those that try and succeed, but porting android to a new platform is hard right now.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 19:29 UTC (Wed) by kragil (guest, #34373) [Link] (1 responses)

Thanks for answering. If it is the case that porting and updating Android is hard then IMHO Google should do everything to make the process easier. The whole purpose of Android is bringing secure internet to more people, isn't it? Then reducing the cost of building those devices should be one of Googles priorities.
BTW although I sound very critical my next Phone will be Android or Maemo and I hope to get a Pixel Qi Android tablet soon. But I hope I will always get an uptodate version of Android on every device. Androids track record in that regard is not stellar. That is another thing upstream friendly development might improve.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 19:33 UTC (Wed) by cdibona (guest, #13739) [Link]

I agree the process should be easier, but I'd say it is easier today than it
was 2+ years ago. But some of these new system on chips are pretty rough
stuff sometimes.

There are some interesting cheaper androids out of HUWEI and some other
manufacturers.

It's okay to be critical :-)

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 19:40 UTC (Wed) by dlang (guest, #313) [Link] (3 responses)

you seem to be contradicting yourself here.

you say that you don't think that forks are bad, but then you say that the linux way of eliminating forks is what has made it better than the *BSDs.

If long-term forks are acceptable, than the *BSDs should be the perfect example to point to as a measure of how they are so successful.

Linux has not had any long-term forks, it came close in the 2.4/2.5 days with Redhat, but even at it's worst it didn't get close to what a separate Android kernel would be or what the different *BSD kernels are.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 4, 2010 7:14 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

Afaik Red Hat carefully backported features to the EL3 kernel after they
have already been mainlined in the development branch of Linux That's
quite different from what Google is doing and their replies don't improve
the situation

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 4, 2010 7:37 UTC (Thu) by cdibona (guest, #13739) [Link]

Well, if anything, I was probably unfair to the BSDs, there are some solid , incredibly useful forks of bsd.... OpenBSD comes to mind (but that's gonna start a centithread if I bring that up too much) as does FreeBSD. They're both healthy and have solid direction.

I also happen to think that if you look back on this a few years or four from now, this will all wash out. By 2.8 maybe? :-)

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 8, 2010 7:19 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link]

you say that you don't think that forks are bad, but then you say that the linux way of eliminating forks is what has made it better than the *BSDs.
If long-term forks are acceptable, than the *BSDs should be the perfect example to point to as a measure of how they are so successful.

Part of the reason that Linux works well is because it lets people with good ideas go off to develop them for a while but always with the idea that those good ideas will be brought back into mainline if/when they've proven their worth. That freedom to develop radical new ideas is why the ability to fork is so important. The problem that the BSDs have had is that they haven't done as well with the merging back into mainline part. They've allowed their forks to become permanent splits instead of temporary development projects.

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 4, 2010 15:34 UTC (Thu) by rich0 (guest, #55509) [Link]

Forks aren't always great, but I honestly don't think of forks as being a bad thing and I've tried to instill in Google the same ethic.

The big problem with this sort of approach is that projects on the scale of something like Chrome or Android can turn into entities unto themselves with almost no connection to the projects they were derived from.

The last time I downloaded the chromium source the tarball was around 0.5GB - almost all of it from forked dependencies. The resulting build is unnecessarily long, and it ends up losing any benefit from upstream improvements in any of those dependencies. If zlib or whatever fixes a security flaw I need to download and rebuild another 0.5GB tarball to incorporate the fix.

A company the size of Google can sustain this, I guess, but it makes the resulting project unwieldy. There may not ever be a community-based version of chromium as a result, just as there is no practical community- based version of android out there now (I'd define community-based as a fork with no corporate sponsorship). On the other hand, that need-not remain the situation permanently, and there are signs that Google has been trying to integrate with upstream/etc (but they've dug themselves into a bit of a hole).

Sure, forks aren't always a bad thing, but they can be counterproductive and they can lead to isolation. When there is no reason to persist with a fork it behooves us all to work together if we truly value the open source spirit.