All of lore.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 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.