Subject: Re: Re: Final plug for extra utilities
To: matthew sporleder <msporleder@gmail.com>
From: Erik Berls <cyber@ono-sendai.com>
List: netbsd-users
Date: 09/02/2006 10:06:09
------=_Part_143833_14962393.1157216769682
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Alternately, we could make packages a "required" framework and install any
utilities as part of views. (Thus making /usr/pkg being as required as
/usr/lib or /usr/share. One could take it to the logical extreme and build
the entire system in a pkg views type of framework.)
-=erik.
On 9/2/06, matthew sporleder <msporleder@gmail.com> wrote:
>
> On 9/1/06, Ben Collver <collver@peak.org> wrote:
> > On Fri, Sep 01, 2006 at 10:06:05PM -0400, matthew sporleder wrote:
> > > >perl:
> > > > I'm revoking this one. Perl is too large and complicated, and
> it's
> > > > not required.
> > > Yes, operating systems that include perl/java/python/etc are just
> > > forcing someone to maintain two versions on their system and confuse
> > > everyone a lot.
> >
> > I've seen cluster nodes with a dozen "virtual servers", some of which
> > had multiple versions of Perl with specific build options desired by
> > specific developers. The administrators didn't get confused.
> >
> > But having it built in leads me to wonder if it can be removed, or
> > properly upgraded. For example, parts of Gentoo may depend on Python,
> > or parts of OSX may depend on a JVM. How can one argue in this case
> > that it shouldn't be built in?
> >
>
> The situation goes like this:
> My very important OS utility X depends on Y.
> Y becomes old, out-of-date, insecure.
> In parallel, the OS becomes old, but not really out-of-date. (OS's
> have more useful life than one version of perl)
> New tool Z needs updates Y, I now need two Y's.
>
> Having two Y's now means I need to mess around with #!/path/to/Y
> because, of course, my OS installed old Y in the most common place.
> :)
>
> If you can -avoid- these dependencies all together, you're in a much
> better situation to stay out of that mess.
>
------=_Part_143833_14962393.1157216769682
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Alternately, we could make packages a "required" framework and install any utilities as part of views. (Thus making /usr/pkg being as required as /usr/lib or /usr/share. One could take it to the logical extreme and build the entire system in a pkg views type of framework.)
<br><br>-=erik.<br><br><br><div><span class="gmail_quote">On 9/2/06, <b class="gmail_sendername">matthew sporleder</b> <<a href="mailto:msporleder@gmail.com">msporleder@gmail.com</a>> 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 9/1/06, Ben Collver <<a href="mailto:collver@peak.org">collver@peak.org</a>> wrote:<br>> On Fri, Sep 01, 2006 at 10:06:05PM -0400, matthew sporleder wrote:<br>> > >perl:<br>> > > I'm revoking this one. Perl is too large and complicated, and it's
<br>> > > not required.<br>> > Yes, operating systems that include perl/java/python/etc are just<br>> > forcing someone to maintain two versions on their system and confuse<br>> > everyone a lot.
<br>><br>> I've seen cluster nodes with a dozen "virtual servers", some of which<br>> had multiple versions of Perl with specific build options desired by<br>> specific developers. The administrators didn't get confused.
<br>><br>> But having it built in leads me to wonder if it can be removed, or<br>> properly upgraded. For example, parts of Gentoo may depend on Python,<br>> or parts of OSX may depend on a JVM. How can one argue in this case
<br>> that it shouldn't be built in?<br>><br><br>The situation goes like this:<br>My very important OS utility X depends on Y.<br>Y becomes old, out-of-date, insecure.<br>In parallel, the OS becomes old, but not really out-of-date. (OS's
<br>have more useful life than one version of perl)<br>New tool Z needs updates Y, I now need two Y's.<br><br>Having two Y's now means I need to mess around with #!/path/to/Y<br>because, of course, my OS installed old Y in the most common place.
<br>:)<br><br>If you can -avoid- these dependencies all together, you're in a much<br>better situation to stay out of that mess.<br></blockquote></div><br>
------=_Part_143833_14962393.1157216769682--