linux-kernel - Re: Evolution of kernel size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111110161915.GA28282@comet.deepsky.org>
Date:	Fri, 11 Nov 2011 01:19:15 +0900
From:	Jérôme Pinot <ngc891@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Evolution of kernel size

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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/