From owner-freebsd-hackers Tue Nov 26 15:44:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA03331 for hackers-outgoing; Tue, 26 Nov 1996 14:34:55 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA03303 for ; Tue, 26 Nov 1996 14:34:46 -0800 (PST) From: Lotus_Mail_Exchange@CSERVE4.CCMAIL.compuserve.com Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id LAA13000 for ; Tue, 26 Nov 1996 11:58:32 -0800 (PST) Received: from hil-img-1.compuserve.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vSTeC-0008taC; Tue, 26 Nov 96 11:58 PST Received: by hil-img-1.compuserve.com (8.6.10/5.950515) id OAA17429; Tue, 26 Nov 1996 14:54:40 -0500 Date: Tue, 26 Nov 1996 12:04:17 -0500 Subject: NON-DELIVERY of: hackers-digest V1 #1663 To: "INTERNET:hackers@freefall.freebsd.org" Message-ID: <199611261454_MC1-C33-929F@compuserve.com> Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk 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: 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 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 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 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 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 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 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" 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. 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" 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" 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 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 ******************************