[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-current-users
Subject:    Re: A proposal on how to further handle ports
From:       "Blair Sadewitz" <blair.sadewitz () gmail ! com>
Date:       2006-09-27 2:35:56
Message-ID: 6e9741c60609261935i10960432k195b4766eab38ff9 () mail ! gmail ! com
[Download RAW message or body]

I do not think this proposal is congruent with NetBSD's ideology nor its
goals.  I agree with a previous poster that deeming a port "completed yet
supported" is simply euphemistically EOL'ing it.

NetBSD can only be "finished" in the sense that someone's career is
"finished", i.e. no more work will ever be done.  Given the constant flux
intrinsic to its distributed, open model of development, portions of the
code base may lie stangnant for a while until someone comes along to develop
them, e.g. the LFS file system; these dynamics are cyclical and complex.  A
recent example of the concepts I'm highlighting is the addition of
timecounter support to each platform.  If a port is marked "completed", they
will necessarily be at least somewhat excluded from this process.  IMHO,
the current scheme of "experimental" vs. "mature" ports is well-suited to
NetBSD.

Think about it: how can a port which is complete be supported if support
entails development?  Bug fixes do not suffice on their own; at times, there
must be major rewrites.  Your notion of a "completed, yet supported" port is
commonly known as "legacy" software.  NetBSD's emphasis on elegant
portability is incompatible with categorizing some ports as "legacy";
supporting many old platforms is not merely an esoteric pursuit irrelevant
to the mainstream!  Rather, it helps to ensure coherency, scalability, and
stability.  Code which runs well on embedded systems which seem
resource-starved compared to the most modest desktop PC seems--to me**, at
least--way more likely to scale well:  Compare Windows CE running an a PDA
vs XP on the desktop, and then think of NetBSD on a PDA vs. NetBSD on the
desktop!  Windows CE is scaled down, whereas NetBSD, in most cases, simply
scales up.  Thus, having ports which are not production quality [yet]
benefits the ports which are.

Am I on target here?  I like to know if I make sense or not. ;)

--Blair


** A lot of this is simply the rumen of materials I've read combined with my
own philosophical cogitation, i.e. I am not a professional in this field.

On 9/26/06, Dennis den Brok <d.den.brok@uni-bonn.de> wrote:
>
> On Tue, 26 Sep 2006 13:15:40 -0700
>   Bill Studenmund <wrstuden@netbsd.org> wrote: A lot that
> appears plausible enough to me to make me draw back my
> suggestion. ;-)
>
> Sorry for the noise, the badly formatted e-mail, and the
> blank reply to Bill's mail (I really shouldn't be learning
> BSD 'nail' when submitting to a public list) to all
> subscribers.
>
> Best regards,
>
> Dennis den Brok
>

[Attachment #3 (text/html)]

I do not think this proposal is congruent with NetBSD's ideology nor its goals.&nbsp; \
I agree with a previous poster that deeming a port &quot;completed yet \
supported&quot; is simply euphemistically EOL'ing it.<br><br>NetBSD can only be \
&quot;finished&quot; in the sense that someone's career is &quot;finished&quot;,  \
i.e. no more work will ever be done.&nbsp; Given the constant flux intrinsic to its \
distributed, open model of development, portions of the code base may lie stangnant \
                for a while until someone comes along to develop them, e.g
. the LFS file system; these dynamics are cyclical and complex.&nbsp; A recent \
example of the concepts I'm highlighting is the addition of timecounter support to \
each platform.&nbsp; If a port is marked &quot;completed&quot;, they will necessarily \
be at least somewhat excluded from this process.&nbsp; IMHO,&nbsp; the current scheme \
of &quot;experimental&quot; vs. &quot;mature&quot; ports is well-suited to NetBSD. \
<br><br>Think about it: how can a port which is complete be supported if support \
entails development?&nbsp; Bug fixes do not suffice on their own; at times, there \
must be major rewrites.&nbsp; Your notion of a &quot;completed, yet supported&quot; \
port is commonly known as &quot;legacy&quot; software.&nbsp; NetBSD's emphasis on \
elegant portability is incompatible with categorizing some ports as \
&quot;legacy&quot;; supporting many old platforms is not merely an esoteric pursuit \
irrelevant to the mainstream!&nbsp; Rather, it helps to ensure coherency, \
scalability, and stability.&nbsp; Code which runs well on embedded systems which seem \
resource-starved compared to the most modest desktop PC seems--to me**, at least--way \
more likely to scale well:&nbsp; Compare Windows CE running an a PDA vs XP on the \
desktop, and then think of NetBSD on a PDA vs. NetBSD on the desktop!&nbsp; Windows \
CE is scaled down, whereas NetBSD, in most cases, simply scales up.&nbsp; Thus, \
having ports which are not production quality [yet] benefits the ports which are. \
<br><br>Am I on target here?&nbsp; I like to know if I make sense or not. \
;)<br><br>--Blair<br><br><br>** A lot of this is simply the rumen of materials I've \
read combined with my own philosophical cogitation, i.e. I am not a professional in \
this field.  <br><br><div><span class="gmail_quote">On 9/26/06, <b \
class="gmail_sendername">Dennis den Brok</b> &lt;<a \
href="mailto:d.den.brok@uni-bonn.de">d.den.brok@uni-bonn.de</a>&gt; \
wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Tue, 26 Sep 2006 \
13:15:40 -0700<br>&nbsp;&nbsp;Bill Studenmund &lt;<a \
href="mailto:wrstuden@netbsd.org">wrstuden@netbsd.org</a>&gt; wrote: A lot \
that<br>appears plausible enough to me to make me draw back my<br>suggestion. ;-)<br> \
<br>Sorry for the noise, the badly formatted e-mail, and the<br>blank reply to Bill's \
mail (I really shouldn't be learning<br>BSD 'nail' when submitting to a public list) \
to all<br>subscribers.<br><br>Best regards,<br><br> Dennis den \
Brok<br></blockquote></div><br>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic