public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Richard Moser <nigelenki@comcast.net>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-kernel@vger.kernel.org
Subject: Re: Driver model.. expel legacy drivers?
Date: Sat, 14 Oct 2006 16:48:32 -0400	[thread overview]
Message-ID: <45314D20.7060904@comcast.net> (raw)
In-Reply-To: <200610141854.k9EIs2CN005765@laptop13.inf.utfsm.cl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Horst H. von Brand wrote:
> John Richard Moser <nigelenki@comcast.net> wrote:
> 
> [...]
> 
>> I've mapped the growth of the .tar.bz2 archives in kilobytes since
>> 2.6.0, they show an erratic pattern but a strong overall linear growth
>> pattern.  This means the actual size of the kernel is polynomial and
>> integrates crudely to:
>>
>>    18.59x^2+133.1x+32600
>>
>> For x == minor (i.e. 2.6.0 == 0; 2.6.18 == 18).  This produces a level
>> of error; however, I've graphed the error and it seems to be off by no
>> more than 400k ever and show a horizontal trend (i.e. overall accurate);
>> however I'll have to apply the same prediction to future kernel versions
>> to get a good picture.
> 
> Hum... perhaps going against time (not minor) is better?
> 

I think revisions have an average time between them that follows a
general linear trend.  {1 4 3 1 0 2 2 3} is a general linear trend; a
line between these points best dividing half above and half below is
horizontal.  *The assertion that revision numbers are linearly
correlated to time is a conjecture; I have not verified this
mathematically.*

> You could also include the whole 2.5.x set (at least since git became
> common) for a larger series...

Perhaps, but that was a heavy development period and I want to avoid
lurking variables; otherwise I'd have included 2.4's whole series too.
I know this is a lost cause in 2.6, what with things like devfs or OSS
dropping and ALSR getting merged in at random times....

> 
> [...]
> 
>> My math predicts that 2.6.57 (+39) will be 100M (in approximately 7
>> years if you assume 1 kernel release every 2 months); 2.6.92 (+35) will
>> breech 200M; 2.6.117 (+25) will breech 300M; and 2.6.138 (+21)) will
>> breech 400M.  That should suffice for predictions over the next 20 years
>> based on this crude model.
> 
> I'd trust your curve for, say, 5 minors. Not more. The quadratic term is
> rather hard to justify in any case... linear growth (== new drivers at a
> (roughly) constant rate, a (roughly) constant number of people actively
> working on the kernel with constant productivity, ...) I give you easily.

(ax^2 + bx + c)d/dx == 2ax + b

I didn't eye the curve as quadratic; I eyed it as a gentle curve.  I
took the differences and looked for a trend specifically because I know
a linear growth trend (polynomial degree 1) indicates a quadratic trend
(polynomial degree 2).

As I said, I don't have enough samples.  I only used 16 of the 19
samples I have to generate the function above; I would like upwards of
30 before claiming any useful trend.

- --
    We will enslave their women, eat their children and rape their
    cattle!
                  -- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBRTFDnws1xW0HCTEFAQLLHA//WxyEu7Tzh/Lt6RAWL3qA1xHHm2E2WWBc
bUCq4ONuXheZ9rdQM0VHdLIdkPNvkFPtBXSugEIPCIMDSjR8+z1U+kv96Od96Gb0
TfSLMGIUnVzdhAHzwTo35vfPrQb3dIVA4j+3dgMHX0e+OEWDeHhHsAWSjgkwqhe4
OQ6SvCZVIxV2nFTJ3MkbNqITVBNmWy4cy16L3H6GiiQl/q3tg71Dochcn83ySNlc
9NCP4igLVlfjThNCK8pJtDoZX887oCFB/npSOSiwKQKciAlMooAgmDRTh55pa7D4
XD+Lilxwp/jFXbtv/9HdoETeN7kZLcVYbGfMosDvwxl5g2smzCLWEv5qvUCs3lDQ
gh4knxGF59Vupou+irI9L+1FC3irJcS92x3ITFQwwTRT3rZ5hVMPIBaxovWN2oVY
U0InH4VhLY+yWADL3BkWEi/pNQ2YxiXw5VdSDHMitBHEczOyE2emAkVTBvuGl/wP
v2iDVHJU9A1IMsN0EG+C+hpOR4kqIU/WT/aLAC3JwUKb+RTFadgRdYs6/ca++2ks
iFwA55Dd20iQ3p/uCwXMvugWAGwo+tPXHIBJy3RSnPkL4r/CaA1RwC7Gn/EDqgeA
w2jO6hYcKKX91MEFpfvqUjNx5Oq4gHf/20rLQi7kMW12LVkVDmKZe840KETSt3Wb
O8MAMIs894s=
=6G+v
-----END PGP SIGNATURE-----

  reply	other threads:[~2006-10-14 20:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-14  3:18 Driver model.. expel legacy drivers? John Richard Moser
2006-10-14  7:56 ` Adrian Bunk
2006-10-14 11:19   ` James Courtier-Dutton
2006-10-14 15:04   ` John Richard Moser
2006-10-14 18:54     ` Horst H. von Brand
2006-10-14 20:48       ` John Richard Moser [this message]
2006-10-15 15:31       ` Jan Engelhardt
2006-10-14 21:14     ` Kevin K
2006-10-14 21:44       ` John Richard Moser
2006-10-15  0:03         ` Alan Cox
2006-10-14 23:51           ` John Richard Moser
2006-10-15  1:24             ` Kevin K
2006-10-15  1:51               ` Alistair John Strachan
2006-10-15 14:33             ` Alan Cox
2006-10-16  9:39               ` Kasper Sandberg
2006-10-16 14:13                 ` Lee Revell
2006-10-16 19:04                   ` Lennart Sorensen

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=45314D20.7060904@comcast.net \
    --to=nigelenki@comcast.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox