Date: Tue, 26 Nov 1996 12:04:17 -0500 From: Lotus_Mail_Exchange@CSERVE4.CCMAIL.compuserve.com To: "INTERNET:hackers@freefall.freebsd.org" <hackers@freefall.freebsd.org> Subject: NON-DELIVERY of: hackers-digest V1 #1663 Message-ID: <199611261454_MC1-C33-929F@compuserve.com>
next in thread | raw e-mail | index | archive | help
Sender: owner-hackers-digest@freefall.freebsd.org
Received: from smyrno.sol.net (smyrno.sol.net [206.55.64.117]) by arl-img-1.compuserve.com (8.6.10/5.950515)
id IAA04351; Thu, 21 Nov 1996 08:54:17 -0500
From: <owner-hackers-digest@freefall.freebsd.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.18]) by smyrno.sol.net (8.8.3/8.8.3) with ESMTP id HAA00790; Thu, 21 Nov 1996 07:44:52 -0600 (CST)
Received: (from root@localhost)
by freefall.freebsd.org (8.7.5/8.7.3) id FAA22198
for freebsd-hackers-digest-outgoing; Thu, 21 Nov 1996 05:00:14 -0800 (PST)
Date: Thu, 21 Nov 1996 05:00:14 -0800 (PST)
Message-Id: <199611211300.FAA22198@freefall.freebsd.org>
To: freebsd-hackers-digest@FreeBSD.ORG
Subject: hackers-digest V1 #1663
Reply-To: hackers@freefall.freebsd.org
Errors-To: owner-hackers-digest@freefall.freebsd.org
Precedence: bulk
hackers-digest Thursday, 21 November 1996 Volume 01 : Number 1663
In this issue:
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: Is FastVid implemented on XFree86?
Re: socket.h
Re: Is FastVid implemented on XFree86?
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: Ipx to ip routing
vx driver problems
Re: WordPerfect 7.0 for FreeBSD :-)
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: Help identifying a compressed file
----------------------------------------------------------------------
From: davidn@sdev.usn.blaze.net.au (David Nugent)
Date: Thu, 21 Nov 1996 15:07:43 +1100
Subject: Re: Who needs Perl? We do!
Michael Smith writes:
> > Yes, I use it quite a bit, but in a base distribution I don't really
> > see it as an appropriate tool. It is certainly easier that programming
> > in, say, bourne shell, and probably significantly faster too. But I
> > still think it is a mistake it being part of the base system.
>
> I think that there's a very important line to be drawn between "I
> don't think I need it in the system" and "It should not be in the
> system".
Agreed. But there's also the distinction between "needed" and
"desired". Certainly *I* regard Perl as an indispensible tool
for what I do. I'm less certain that everyone else would regard
it in the same light, which is why I still don't think it appropriate
for a *base* distribution.
> My point is that there are a sufficient number of people that consider
> Perl a 'should-have' to justify its inclusion on those grounds.
>From a more pragmatic standpoint, I disagree.
Yes, lots of people want or need it in what they do, but whether it
is *needed* to run/install/build the base system is a different
question. Right now there is some dependance on perl (and using an
outdated and unsupported version), but my worry is that it being
there in the first place is more likely to increase that dependance.
The point is not really whether perl4 disappears or not (it *must* do
so eventually - it is, as I said, old and unsupported) but whether
perl5 is needed in the base distribution.
Perl5 is huge and is delivered with quite a deal of bloat. Too big
for the small dependancies that currently exist. If we used perl
and most the anciliary modules and the scripts which depended on it
could not be so easily replaced (and I'll admit that sgmlfmt appears
to be one of those), then it would be justified.
> The latter point bears discussion; someone putting this point needs to
> offer a counter to the benefits promised by the former. So far, most
> of the arguments have been "because I don't think it should be" (which
> counts for very little), or "because Perl keeps changing" (which has
> been comprehensively refuted by Perl users I am inclined to trust).
Yes, the "keeps changing" argument is indeed bogus. There are one
or two minor syntactic changes, which later versions of perl have
built-in warnings for are easily handled, certainly easily enough
done for the scripts that are actually installed under -current.
> Other arguments that have been offered for the latter in previous
> discussions; "Perl is too big" (size is relative, disk is cheap),
> "Perl would be too hard to track" (contrib scheme should fix this).
>
> I'm still open to argument on this; I just haven't heard a counter
> that holds up under scrutiny.
If all that was required for a proper perl5 distribution was the
perl executable itself, I'd have no real argument. It is all of
the unneeded (for the *base* distribution) cruft that comes with
it that is the problem. Even perl4 has this problem to a lesser
extent, but as I read it, this (size/unnecessary bloat problem)
is the root of the reluctance to upgrade perl4 to perl5.
Central to my argument is that perl4 is no longer viable. Either
perl should be removed completely from the base distribution, or
it should be upgraded to perl5. Personally, I favour removal,
because I'm a purist (a self-admitted fault :-)). This is not to
say that perl is not useful - *IT IS* - but that, like many other
useful things, it should be an addition to the base system. Even
in -current, we don't win very much from the expense of having it
(again, with the exception of sgmlfmt).
Regards,
David Nugent, Unique Computing Pty Ltd - Melbourne, Australia
Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet
davidn@blaze.net.au http://www.blaze.net.au/~davidn
------------------------------
From: Michael Smith <msmith@atrad.adelaide.edu.au>
Date: Thu, 21 Nov 1996 14:57:16 +1030 (CST)
Subject: Re: Who needs Perl? We do!
David Nugent stands accused of saying:
> >
> > I think that there's a very important line to be drawn between "I
> > don't think I need it in the system" and "It should not be in the
> > system".
>
> Agreed. But there's also the distinction between "needed" and
> "desired". Certainly *I* regard Perl as an indispensible tool
> for what I do. I'm less certain that everyone else would regard
> it in the same light, which is why I still don't think it appropriate
> for a *base* distribution.
It's not a question of whether _everyone_ needs it, but whether a
sufficient number of people need it. I think that so far the evidence
indicates that this is the case.
>
> Yes, lots of people want or need it in what they do, but whether it
> is *needed* to run/install/build the base system is a different
> question. Right now there is some dependance on perl (and using an
> outdated and unsupported version), but my worry is that it being
> there in the first place is more likely to increase that dependance.
If the only criteria for the 'base' system was whether the tool was
required to build the system, FreeBSD would me much skinnier. I
seriously doubt that anyone would consider that a useful criteria on
which to judge something's "membership rights".
> Perl5 is huge and is delivered with quite a deal of bloat. Too big
> for the small dependancies that currently exist. If we used perl
You are still thinking of Perl in the light of its use as support for
other things in the system, rather than as a standard service for
users. It is this latter case that most strongly argues for Perl in
the tree, as with Tcl.
> If all that was required for a proper perl5 distribution was the
> perl executable itself, I'd have no real argument. It is all of
> the unneeded (for the *base* distribution) cruft that comes with
> it that is the problem. Even perl4 has this problem to a lesser
> extent, but as I read it, this (size/unnecessary bloat problem)
> is the root of the reluctance to upgrade perl4 to perl5.
If the bloat is truly excessive, then it belongs in a seperate
distribution (eg. perl-support) that can be added to the system if
required. I seriously doubt whether the alleged 'bloat' would
actually be significant in the big picture.
I would hope that the growth of the "standard footprint" of FreeBSD
would encourage the minimalist faction to actually extract their
digits and do something about identifying the "core" of the system and
making it a base component.
I'm entirely in agreement with the basic principle, but I strongly
believe that we need to incorporate mature and ubiquitous tools in
as seamless and standard a fashion as possible.
> David Nugent, Unique Computing Pty Ltd - Melbourne, Australia
- --
]] Mike Smith, Software Engineer msmith@gsoft.com.au [[
]] Genesis Software genesis@gsoft.com.au [[
]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[
]] realtime instrument control. (ph) +61-8-8267-3493 [[
]] Unix hardware collector. "Where are your PEZ?" The Tick [[
------------------------------
From: Mark Mayo <mark@quickweb.com>
Date: Wed, 20 Nov 1996 23:39:11 -0500 (EST)
Subject: Re: Is FastVid implemented on XFree86?
On Sun, 27 Oct 1996, Amancio Hasty wrote:
>
> Tnks,
> Amancio
>
I was just wondering if you got a reply either way... I'm pretty sure it's
not. I noticed, however, that if I run FastVid from a DOS boot, then do a
"soft reboot = CTRL+ALT+DEL" the chipset/CPU isn't reset!
So I get nice fast video with my 82450GX chipset PPro. Happy. However, on
several occasions, it has caused AccleX, xdm, fvwm to core dump -- to the
point that xdm wouldn't even start up again :-( If I do a hardware reset
everything starts working again.
Overall, _my_ system seems quite stable with the FastVid stuff turned on,
but it does seem to be a problem some times...
- -Mark
>
>
- ---------------------------------------------------
| Mark Mayo mark@quickweb.com |
| RingZero Comp. vinyl.quickweb.com/mark |
- ---------------------------------------------------
"To iterate is human, to recurse divine."
- L. Peter Deutsch
------------------------------
From: Bill Fenner <fenner@parc.xerox.com>
Date: Wed, 20 Nov 1996 20:56:32 PST
Subject: Re: socket.h
You want to cast the sockaddr_in to a sockaddr, as in
> if (connect(SocketDescriptor, (struct sockaddr *) &SocketInetAddr,
>sizeof(SocketInetAddr)) < 0)
You'll notice if you look carefully that "struct sockaddr" and "struct
sockaddr_in" are the same size and the "family" and "length" fields
overlap.
I'd strongly reccommend "Unix Network Programming", by Richard Stevens, as
a reference for networking programs like this.
Bill
------------------------------
From: Amancio Hasty <hasty@rah.star-gate.com>
Date: Wed, 20 Nov 1996 21:11:34 -0800
Subject: Re: Is FastVid implemented on XFree86?
Silence and on this front. I like your info and I will try it out
over here. Is just that I rarely boot dos on this box .
Tnks for the info!
Amancio
>From The Desk Of Mark Mayo :
> On Sun, 27 Oct 1996, Amancio Hasty wrote:
>
> >
> > Tnks,
> > Amancio
> >
>
> I was just wondering if you got a reply either way... I'm pretty sure it's
> not. I noticed, however, that if I run FastVid from a DOS boot, then do a
> "soft reboot = CTRL+ALT+DEL" the chipset/CPU isn't reset!
>
> So I get nice fast video with my 82450GX chipset PPro. Happy. However, on
> several occasions, it has caused AccleX, xdm, fvwm to core dump -- to the
> point that xdm wouldn't even start up again :-( If I do a hardware reset
> everything starts working again.
>
>
> Overall, _my_ system seems quite stable with the FastVid stuff turned on,
> but it does seem to be a problem some times...
>
> -Mark
> >
> >
> ---------------------------------------------------
> | Mark Mayo mark@quickweb.com |
> | RingZero Comp. vinyl.quickweb.com/mark |
> ---------------------------------------------------
> "To iterate is human, to recurse divine."
> - L. Peter Deutsch
>
------------------------------
From: Michael Hancock <michaelh@cet.co.jp>
Date: Thu, 21 Nov 1996 14:22:27 +0900 (JST)
Subject: Re: Who needs Perl? We do!
On Thu, 21 Nov 1996, Michael Smith wrote:
> It's not a question of whether _everyone_ needs it, but whether a
> sufficient number of people need it. I think that so far the evidence
> indicates that this is the case.
>
I prefer having it in ports or a different distribution so that it can be
excluded easier. The people who want it excluded include those who don't
care about having perl 5.0 and those who would rather track it
and configure it themselves.
If it must be put in the base then can we replace perl 4.0 without causing
an uproar? Also, can we agree on the options included?
I really don't want to see 2 different releases of perl in the base
distribution.
Perl's size is significant, especially when you consider that it will be
in the cvs tree, the installation, and the checked out sources. Double it
if you have both 4.x and 5.x.
Regards,
Mike Hancock
------------------------------
From: Michael Smith <msmith@atrad.adelaide.edu.au>
Date: Thu, 21 Nov 1996 16:20:46 +1030 (CST)
Subject: Re: Who needs Perl? We do!
Michael Hancock stands accused of saying:
> On Thu, 21 Nov 1996, Michael Smith wrote:
>
> > It's not a question of whether _everyone_ needs it, but whether a
> > sufficient number of people need it. I think that so far the evidence
> > indicates that this is the case.
>
> I prefer having it in ports or a different distribution so that it can be
> excluded easier. The people who want it excluded include those who don't
> care about having perl 5.0 and those who would rather track it
> and configure it themselves.
If it's to be useful in the base system, there needs to be a segregation
between the 'runtime' configuration and the 'development' configuration
then. This is one for the Perl advocates to settle.
> If it must be put in the base then can we replace perl 4.0 without causing
> an uproar? Also, can we agree on the options included?
I think that replacing Perl 4 would be trivial; the dependant components
of the base system are known to work with perl5, and the general opinion
is that little is significantly different.
> Perl's size is significant, especially when you consider that it will be
> in the cvs tree, the installation, and the checked out sources. Double it
> if you have both 4.x and 5.x.
There is no way that Perl 4 would be retained. Perl's size is not a real
issue; people just need stop thinking that 5M is "big" 8)
> Mike Hancock
- --
]] Mike Smith, Software Engineer msmith@gsoft.com.au [[
]] Genesis Software genesis@gsoft.com.au [[
]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[
]] realtime instrument control. (ph) +61-8-8267-3493 [[
]] Unix hardware collector. "Where are your PEZ?" The Tick [[
------------------------------
From: "Jeffery T. White" <zellion@cyberwind.com>
Date: Wed, 20 Nov 1996 22:32:39 -0800
Subject: Re: Ipx to ip routing
> And we want to eliminate the need for so many ip addresses so that we
> can get rid of all the ip address conflicts that we can't seem to trace
> down.
Unless you have more machines than IP numbers DHCP really is a pretty good
solution. I set it up at work and it was great. Not only could you assign
IP address that way but you can distribute default gateway, DNS, netmask
and all kinds of other IP config data from the DHCP server. That way when
you maybe change a name server or something you only have to update it in
one place.
We used the Windoze NT DHCP Service so I don't know first hand how the BSD
ones are but I can only assume they are as good or better<g>.
The only down side of switching to DHCP is you have to reconfigure all the
existing machines pretty much at once since your addresses are probably all
over right now and the DHCP server will assign them sequentially from the
blocks you allocate.
Of course if users still insist on entering an address that will mess
things up. Not as bad as before though because you will have the DHCP data
from which you can get a list of all the machines with _legal_ addresses.
The missing machines either haven't been turned on within the expiration
period or are owned by users who require their little fingers to be broken
:-)...
| Jeffery T. White
| email: zellion@cyberwind.com
|
| Cyberwind, The wind knows...
| http://www.cyberwind.com
------------------------------
From: "Jon Morgan" <morgan@terminus.trailblazer.com>
Date: Wed, 20 Nov 1996 23:02:14 -0800
Subject: vx driver problems
I found problems in if_vx.c where the driver handles ifconfig link[012] flags.
The driver is ANDing the index into the connector_table rather than the
actual bit value out of the table.
Here's the code for 2.1.6-RELEASE that fixes the problem:
*** if_vx.c.orig Wed Nov 20 20:07:59 1996
- --- if_vx.c Wed Nov 20 21:45:35 1996
***************
*** 355,365 ****
* (if present on card or AUI if not).
*/
/* Set the xcvr. */
! if(ifp->if_flags & IFF_LINK0 && sc->vx_connectors & CONNECTOR_AUI) {
i = CONNECTOR_AUI;
! } else if(ifp->if_flags & IFF_LINK1 && sc->vx_connectors & CONNECTOR_BNC)
{
i = CONNECTOR_BNC;
! } else if(ifp->if_flags & IFF_LINK2 && sc->vx_connectors & CONNECTOR_UTP)
{
i = CONNECTOR_UTP;
} else {
i = sc->vx_connector;
- --- 355,365 ----
* (if present on card or AUI if not).
*/
/* Set the xcvr. */
! if(ifp->if_flags & IFF_LINK0 && sc->vx_connectors &
connector_table[CONNECTOR_AUI].bit) {
i = CONNECTOR_AUI;
! } else if(ifp->if_flags & IFF_LINK1 && sc->vx_connectors &
connector_table[CONNECTOR_BNC].bit) {
i = CONNECTOR_BNC;
! } else if(ifp->if_flags & IFF_LINK2 && sc->vx_connectors &
connector_table[CONNECTOR_UTP].bit) {
i = CONNECTOR_UTP;
} else {
i = sc->vx_connector;
and here's the equivalent code for 3.0-CURRENT (I havn't tested this, but it
should be the same):
*** if_vx.c.orig Wed Nov 20 20:07:59 1996
- --- if_vx.c Wed Nov 20 21:45:35 1996
***************
*** 355,365 ****
* (if present on card or AUI if not).
*/
/* Set the xcvr. */
! if(ifp->if_flags & IFF_LINK0 && sc->vx_connectors & CONNECTOR_AUI) {
i = CONNECTOR_AUI;
! } else if(ifp->if_flags & IFF_LINK1 && sc->vx_connectors & CONNECTOR_BNC)
{
i = CONNECTOR_BNC;
! } else if(ifp->if_flags & IFF_LINK2 && sc->vx_connectors & CONNECTOR_UTP)
{
i = CONNECTOR_UTP;
} else {
i = sc->vx_connector;
- --- 355,365 ----
* (if present on card or AUI if not).
*/
/* Set the xcvr. */
! if(ifp->if_flags & IFF_LINK0 && sc->vx_connectors &
connector_table[CONNECTOR_AUI].bit) {
i = CONNECTOR_AUI;
! } else if(ifp->if_flags & IFF_LINK1 && sc->vx_connectors &
connector_table[CONNECTOR_BNC].bit) {
i = CONNECTOR_BNC;
! } else if(ifp->if_flags & IFF_LINK2 && sc->vx_connectors &
connector_table[CONNECTOR_UTP].bit) {
i = CONNECTOR_UTP;
} else {
i = sc->vx_connector;
------------------------------
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Date: Thu, 21 Nov 1996 00:17:08 -0800
Subject: Re: WordPerfect 7.0 for FreeBSD :-)
> That's the 3th time that I talk with guy at Corel about WP 7.0.
First, please don't spam so many lists at once - that's just bad
manners and not encouraged at all. Thanks.
Second, what you should tell Coral to do is send us a copy of the
Linux version and we'll try to certify it for use under FreeBSD. I
don't think that Coral should be pushed to do a FreeBSD version until
we have a better idea of the size of our market since pushing them to
do a port and then seeing it sell badly would be worse than no port at
all. It would only screw us for a second chance.
I would be happy if vendors with Linux versions of their products
would give us a chance at certifying it under the emulator and,
if it works, listing it as supported under FreeBSD as well (we
will also have to improve our Linux library support, but that
would be a natural side-effect of the certification process also).
Jordan
------------------------------
From: nik@blueberry.co.uk (Nik Clayton)
Date: Thu, 21 Nov 1996 11:08:21 +0000
Subject: Re: Who needs Perl? We do!
Michael Smith writes:
> I'm entirely in agreement with the basic principle, but I strongly
> believe that we need to incorporate mature and ubiquitous tools in
> as seamless and standard a fashion as possible.
Uh, /usr/ports? pkg_add?
As far as I can see, FreeBSD currently has a few admin scripts written in
Perl (which someone in this thread has already volunteered to re-write
in C). And that's about the extent of it's requirement at the moment.
If J. Random User wants to write a nifty adduser script (or whatever) in
Perl, then great. Even better, encourage them to submit it as a port
with a dependency on a particular Perl port.
Or punt Perl (and other niceties) into a 'recommended' distribution (or
something) and have the install say something like
If you're new to Unix then you may want to look at the
'recommended-software' distribution. This is a collection of
software pre-compiled that you will probably find immediately
useful.
Perl 5.00x
Apache 1.1.1
Elm (or Pine, or whatever)
Adduser
[and so on]
If you're more skilled with Unix, you may want to compile these
programs yourself, using the 'ports' system.
And if you really know what you're doing, you're probably already
running 'ncftp ftp.perl.com/perl/latest.tar.gz' over in another
virtual terminal.
And then you could just have a single port that consists of just a man
page and a bunch of dependencies on the other ports (as listed above).
This man page describes the contents of the 'recommended' distribution,
with pointers on how to get more information about it.
Recommended(1) FreeBSD Reference Manual Recommended(1)
NAME
/usr/bin/perl - The Perl programming language
/usr/libexec/apache - The Apache web server
/usr/sbin/adduser - An easy way to add new users to the system
. . .
DESCRIPTION
Perl
Larry Wall's ubiquitous programming language. Great for scripts
that handle lots of text, and often used in CGI programs for web
pages.
% man perl
for more information.
Apache
Probably the best known free web server, with performance to match
the best of the commercial servers.
See the documentation in /usr/local/share/apache/doc.
Adduser
An interactive script for adding new users to the system. Written
in Perl. Reading the script can be useful as an inkling to the
power of Perl.
% man adduser
for more information.
. . .
and so on.
Create a ports/recommended (or something) category into which stable versions
of software go. ports/lang/perl might be at version 5.4 (fictitious example)
but ports/recommended/perl stays at version 5.003 (or whatever) until
everything else that depends on perl in the 'recommended' category has been
re-written to work with the new version (assuming any re-writing is
necessary).
Thoughts.
N
- --
- --+=[ Blueberry Hill Blueberry New Media ]=+--
- --+=[ http://www.blueberry.co.uk/ 1/9 Chelsea Harbour Design Centre, ]=+--
- --+=[ WebMaster@blueberry.co.uk London, England, SW10 0XE ]=+--
- --+=[ Ten-Thousand-Dimensional Web in Heaven and Net on Earth ]ENTP
------------------------------
From: Michael Smith <msmith@atrad.adelaide.edu.au>
Date: Thu, 21 Nov 1996 22:47:24 +1030 (CST)
Subject: Re: Who needs Perl? We do!
Nik Clayton stands accused of saying:
> Michael Smith writes:
> > I'm entirely in agreement with the basic principle, but I strongly
> > believe that we need to incorporate mature and ubiquitous tools in
> > as seamless and standard a fashion as possible.
>
> Uh, /usr/ports? pkg_add?
*snort* The ports/packages collection is fine as far as it goes, but
you are still failing to understand what I'm on about. I'm talking
about a _basic_system_service_, like the compiler or sendmail.
> As far as I can see, FreeBSD currently has a few admin scripts written in
> Perl (which someone in this thread has already volunteered to re-write
> in C). And that's about the extent of it's requirement at the moment.
What is this blinkered mentality that seems to think that the only
purpose of a system component is to perpetuate the system? Is
everyone disappearing inwards through their own navels?
> If J. Random User wants to write a nifty adduser script (or whatever) in
> Perl, then great. Even better, encourage them to submit it as a port
> with a dependency on a particular Perl port.
Great. Have you been watching the "CVSup is evil because it requires
the monster Modula-3" thread resurfacing every few weeks? Do you
have any idea how unwieldy the ports collection is if you don't
have a (n outdated) copy handy on CDrom?
I try to stay reasonably current at work, but got _seriously_ bitten
this week with a rush to get a couple of notebook systems out the door
for on-the-road demo systems; it's very hard to explain to an anxious
sales jock that you have to download a pile of "oops just changed"
distfiles from the other side of the planet so that they can deal with
whatever printer the customer might have, or whatever.
> Or punt Perl (and other niceties) into a 'recommended' distribution (or
> something) and have the install say something like
Having a "core binaries" distribution, which contained just enought to
boot the system and operate the basic system services, and then
putting everything else in the "basic system services" bundle
(compiler, includes, interpreters, etc) would make sense. Drawing
arbitrary lines based on the phase of the moon just doesn't cut it.
If you like, I am respectfully offering the gauntlet to the
anti-bloatists, and suggesting that they nominate what they feel to be
the core of the system, and then do something about it.
> If you're new to Unix then you may want to look at the
> 'recommended-software' distribution. This is a collection of
> software pre-compiled that you will probably find immediately
> useful.
Completely the wrong way around. The _advanced_ user should be
offered the opportunity to _not_ install these things. The "default
installation" should provide all the services that can be reasonably
and _manageably_ be provided. (This is a key requirement, and is why
I am trying to publically finger people to maintain the proposed
Perl.)
We _do_ need to address the "kitchen sink" issue, and we need a
solution to handle _both_ the 'with' and 'without' cases.
> And if you really know what you're doing, you're probably already
> running 'ncftp ftp.perl.com/perl/latest.tar.gz' over in another
> virtual terminal.
No. What you want is to be able to say "I can write my Excellent New
Application in Perl and know that it can be installed on any
'normally' configured FreeBSD system without significant user grief."
What we're talking about is making it _easier_ to work with FreeBSD
from positions other than the arrogant myopic power-user's point of
view.
> This man page describes the contents of the 'recommended' distribution,
> with pointers on how to get more information about it.
Yuck. Maybe a shellscript (installed when the "core binaries" are)
that writes a message to stderr (and maybe calls 'logger' too) linked
in place of all the binaries containd in the "basic system services"
distribution, observing that said distribution is required.
> Create a ports/recommended (or something) category into which stable versions
> of software go. ports/lang/perl might be at version 5.4 (fictitious example)
> but ports/recommended/perl stays at version 5.003 (or whatever) until
> everything else that depends on perl in the 'recommended' category has been
> re-written to work with the new version (assuming any re-writing is
> necessary).
Aside from a camouflaged 'anti-bloat' stance, you're not actually saying
much new. There's nothing significantly different from the 'contrib'
model there, except that it's extra work to install.
> Thoughts.
Appreciated, even if I don't agree with you.
- --
]] Mike Smith, Software Engineer msmith@gsoft.com.au [[
]] Genesis Software genesis@gsoft.com.au [[
]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[
]] realtime instrument control. (ph) +61-8-8267-3493 [[
]] Unix hardware collector. "Where are your PEZ?" The Tick [[
------------------------------
From: sja@tekla.fi (Sakari Jalovaara)
Date: Thu, 21 Nov 1996 14:57:58 +0200
Subject: Re: Help identifying a compressed file
> Can anybody recognize this fileformat ?
>
> It's some kind of MS/DOS compressed file, but I don't know what program
> were used to compress it :-(
>
>00000000 53 5a 44 44 88 f0 27 33 41 00 88 1c 03 00 ff 3f |SZDD..'3A......?|
>00000010 5f 03 00 c3 35 00 00 7d ff f8 f0 88 1c 03 00 b3 |_...5..}........|
Do an altavista search on the magic number "SZDD". ---------^^^^^
You'll find a bunch of binary files like the one you have. Look for
READMEs near them. You are bound to find one that tells how to unpack.
++sja
------------------------------
End of hackers-digest V1 #1663
******************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611261454_MC1-C33-929F>