From: "Jérôme Pinot" <ngc891@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Evolution of kernel size
Date: Fri, 11 Nov 2011 01:19:15 +0900 [thread overview]
Message-ID: <20111110161915.GA28282@comet.deepsky.org> (raw)
In-Reply-To: <20111110154003.GA14012@elliptictech.com>
On 11/10/11 10:40, Nick Bowler wrote:
> On 2011-11-11 00:15 +0900, Jérôme Pinot wrote:
> > On 11/10/11 09:59, Nick Bowler wrote:
> > > On 2011-11-10 23:33 +0900, Jérôme Pinot wrote:
> > > > I took some time to make a graph of the evolution of the size of the
> > > > linux kernel tar.bz2 since version 1.0 till 3.1 (297 releases).
> > > > It doesn't count the stable branches (2.6.x.y).
> > > >
> > > > Impressive, it's mostly exponential.
> > > > If dev keeps same pace, we should break the 100MB at
> > > > linux 3.19.
> > > >
> > > > You can get the graph on my blog, I provide the data and the
> > > > gnuplot batch file for graphing/fitting:
> > > > http://ngc891.blogdns.net/?p=92
> > > >
> > > > It may interest some people :-)
> > >
> > > What scale did you use for the horizontal axis? I see numbers assigned
> > > to each version in your gnuplot file, but no indication of how you came
> > > up with them.
> >
> > It's just the release count, one step for one release.
> >
> > Some release are missing, mostly at the very beginning, I didn't find
> > tarball for them but it doesn't matter much for the shape of the curve.
>
> The problem with this is that the releases were not made at fixed
> intervals. 2.6.0 -> 3.0 represents more than double the amount of
> development time as 2.4 -> 2.6, yet they get roughly the same amount
> of horizontal space on your plot.
It's because my point was not about studying size(time) but
size(version).
> I think it would be much more interesting to scale by release dates, so
> that the gap between releases is proportional to the time between them.
> I suspect you'll see a very different shape.
It's another point of view which is interesting too.
> Furthermore, looking at the raw data, you gave 2.4.37 (released in 2008)
> a lower release number than 2.6.0 (released in 2003), which seems odd.
Well, branches evolve in parallel, like the 2.4/2.6 move, so you can't
fit these in one unique time-based graph (or it's a mess).
Moreover, code was backported from 2.6 to 2.4 (remember the xfs
thing?), so the 2.4.37 kernel is actually the one from 2.4 branch
to be the more like 2.6.0. It's not a huge nonsense to put the
two releases side by side to compare the code size.
If you like a time-based graph, you'd better to have a graph for each
branch. That's an other work.
--
Jérôme Pinot
http://ngc891.blogdns.net/
next prev parent reply other threads:[~2011-11-10 16:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-10 14:33 Evolution of kernel size Jérôme Pinot
2011-11-10 14:59 ` Nick Bowler
2011-11-10 15:15 ` Jérôme Pinot
2011-11-10 15:40 ` Nick Bowler
2011-11-10 16:19 ` Jérôme Pinot [this message]
2011-11-11 16:51 ` Ted Ts'o
2011-11-12 13:04 ` Jérôme Pinot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111110161915.GA28282@comet.deepsky.org \
--to=ngc891@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.