| |||||||||||||
On the scalability of LinusOn the scalability of LinusPosted Jul 6, 2010 15:48 UTC (Tue) by augustz (subscriber, #37348)Parent article: On the scalability of Linus
If the past is a reasonably good predictor of the future, than Linus performance has been good. I'd suggest there are more wins to this consistency and institutional knowledge then losses. If it ain't broke don't fix it.
If something happens to Linus, also not the end of the world as others point out. The distributors etc will all start pulling from a different tree. Witness the move to a new X tree when the old stagnated. Pretty seamless. Might not be as good, but long term would hopefully stabilize.
If the scalability bottleneck is the ARM junk, there is a real possibility that the ARM churn Linus complains about IS junk and not a scalability issue.
There is a HUGE amount of work going on below linus's tree as the article points out. This is a natural area for scalability, helped by good tooling (basically Git, written interestingly by linus). I do think eventually some deeper structure will happen. At some point Linus will simply not care about some random x. Stick it below a maintainer who does.
Having the light touch dictator keeps the kernel slightly sane, reducing barriers to entry for everyone. For software that'll probably be running in the basements of our future starfleets this can only be a good thing.
- August
(Log in to post comments)
On the scalability of Linus Posted Jul 6, 2010 20:33 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
the ARM problem is that there is no one company that produces ARM chips. ARM is a core thta is licensed to many different companies, and each company adds additional capabilities beyond the core to the chips that they produce.
as a result the number of different chips, each with slightly different capabilities, is staggering.
up until now, each one of these chips has been treated as a different subarchitecture, each with it's own defconfig (which not only has the definitions needed to support that chip/board, but also any other defaults that the maintainer happened to select)
think of the mess that we would have if every chip released by Intel or AMD required a different architecture and you have a glimpse into the mess that is ARM
there is work ongoing to change this and instead of treating every chip as a different architecture, having a different definition file that details what peripherals and options are on each ARM chip/board and how they are hooked up instead of having that information be implicit in the architecture definition.
I think that once this is done there will be even more proliferation of ARM designs as they will be easier to support, but it will be a win-win situation as manufacturers will be able to more easily get the exact chip to fit their application and it will still be easier to support.
|
|||||||||||||