From owner-freebsd-hackers Wed Nov 27 05:15:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA19099 for hackers-outgoing; Wed, 27 Nov 1996 05:15:56 -0800 (PST) Received: from arl-img-5.compuserve.com (arl-img-5.compuserve.com [149.174.217.135]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA19089 for ; Wed, 27 Nov 1996 05:15:53 -0800 (PST) From: Lotus_Mail_Exchange@CSERVE4.CCMAIL.compuserve.com Received: by arl-img-5.compuserve.com (8.6.10/5.950515) id IAA20953; Wed, 27 Nov 1996 08:15:22 -0500 Date: Wed, 27 Nov 1996 08:14:28 -0500 Subject: NON-DELIVERY of: hackers-digest V1 #1667 To: "INTERNET:hackers@freefall.freebsd.org" Message-ID: <199611270815_MC1-BC4-D910@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 hil-img-3.compuserve.com (8.6.10/5.950515) id VAA18199; Thu, 21 Nov 1996 21:21:28 -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 TAA02856; Thu, 21 Nov 1996 19:54:47 -0600 (CST) Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA03743 for freebsd-hackers-digest-outgoing; Thu, 21 Nov 1996 17:29:03 -0800 (PST) Date: Thu, 21 Nov 1996 17:29:03 -0800 (PST) Message-Id: <199611220129.RAA03743@freefall.freebsd.org> To: freebsd-hackers-digest@FreeBSD.ORG Subject: hackers-digest V1 #1667 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 1667 In this issue: Re: the way things are going (Was: Who needs Perl?) WCARCHIVE DOWN AGAIN. Re: Who needs Perl? We do! Re: panic: ffs_valloc: dup alloc Re: New mailing list - CVS-Alert??? Re: Who needs Perl? We do! Re: Who needs Perl? We do! Re: Who needs Perl? We do! Re: Who needs Perl? We do! Re: Who needs Perl? We do! Re: Who needs Perl? We do! Re: Disk Striping Re: Who needs Perl? We do! Re: Who needs Perl? We do! Re: Who needs Perl? We do! ---------------------------------------------------------------------- From: J Wunsch Date: Fri, 22 Nov 1996 00:23:57 +0100 (MET) Subject: Re: the way things are going (Was: Who needs Perl?) As Nate Williams wrote: [Excellent explanation deleted, i fully agree with Nate here.] > That's how things work around here. You don't get 'blessings' or > 'permission' to do something, you do it and then find an advocate to run > with it. After the advocate is happy with your work (or too overloaded > to do it himself), you become a committer and then are one of the > 'blessed/cursed' who are responsible for the whole darn mess. Well, but you forgot: that's exactly the point where the real work begins... ;-) - -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ------------------------------ From: Eric Tremblay Date: Thu, 21 Nov 96 16:21:45 -0800 Subject: WCARCHIVE DOWN AGAIN. CRL called again, WCARCHIVE is down again. 4:21 for the past 30 minutes. Eric "E.T." Tremblay Walnut Creek CDROM eric@cdrom.com ------------------------------ From: Nate Williams Date: Thu, 21 Nov 1996 17:34:44 -0700 (MST) Subject: Re: Who needs Perl? We do! [ Reduced the Cc list down. Please try and minimize the lists ] > > Next point, people are jumping on Perl about how we have so few system > > utils based on it it should go, where are the utils based on TCL? > > Wrong mentality. I have about 20,000 lines of Tcl here in out product > which load a couple of custom libraries and talk to our hardware. This > is what having Tcl in the tree is about, and is why I see Perl in the > tree as a Very Good Thing. But the policy is that nothing belongs in the 'src' tree unless something else relies on it. You can get TCL via the ports (or could have until we brought it into the tree) and it should have stayed there since nothing still uses it and it's been over 5 months. I complained when it was brought in and was told 'Real Soon Now', but nothing has happened. It's simply bloat that is useless to *most* users, and has no use in the main tree. I'm willing to be proven wrong, but unless that happens soon I'm gonna stay in the 'complain and moan' camp. (I *HATE* seeing stupid TCL man-pages that come up instead of the C routines). Nate ------------------------------ From: "Gary Palmer" Date: Thu, 21 Nov 1996 19:33:26 -0500 Subject: Re: panic: ffs_valloc: dup alloc Thomas David Rivers wrote in message ID <199611161253.HAA26583@lakes.water.net>: > > root@mail:/var/crash> gdb -k kernel vmcore.2 > > GDB is free software and you are welcome to distribute copies of it > > under certain conditions; type "show copying" to see the conditions. > > There is absolutely no warranty for GDB; type "show warranty" for details. > > GDB 4.13 (i386-unknown-freebsd), > > Copyright 1994 Free Software Foundation, Inc... > > IdlePTD 1d5000 > > current pcb at 1abd64 > > panic: ffs_valloc: dup alloc > > #0 boot (howto=260) at ../../i386/i386/machdep.c:912 > > 912 } else { > > (kgdb) bt > Welcome to the club :-) > This is the panic that I have had for several months, which is > duplicated almost every night. Well, it just bit me again :-( > Rest assured that several people are investigating this at this > time... > I believe it has something to do with the inode allocation bits in > ffs_valloc(). Others believe some race conditions in vnode allocation > are to blaim, etc... David Greene is investigating other avenues. > It seems to me that we are closing in on the issue, if only by > eliminating everything else :-) Question: it's always the same FS with me that bites the dust. Perhaps a previous crash of the machine caused a FS corruption fsck isn't picking up on. Has anyone who is being bothered by this dumped the fs with *tar* (not dump) and resored to see if that fixes the problem? Gary - -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info ------------------------------ From: cracauer@wavehh.hanse.de (Martin Cracauer) Date: Fri, 22 Nov 96 01:14:06 +0100 Subject: Re: New mailing list - CVS-Alert??? >I would like to propose a new mailing list. It would be called cvs-alert >and wuold be for those times that someone makes a commit that requires >either massive changes to way something is done or re-compiles >of programs. The sequence of actions to compile a kernel and then the world is almost always the same (includes, config, kernel, compiler). I wrote down some of it at (was for NetBSD, but applies to FreeBSD, too): http://www.bik-gmbh.de/~cracauer/bsd-to-current.html Besides getting a world to build, there's another issue: if you don't do a make world everytime you have a new tree, how to find out what programs need to be recompiled? One example are tools that depend on kernel data structure layout. The right thing to solve this is to make sure you rebuild such programs when include files they reference changes. Traversing /usr/src/*bin* that already has was compile at some time and an individual 'make depend' should do the job. Martin - -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://cracauer.cons.org Fax +49405228536 "As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin ------------------------------ From: Michael Smith Date: Fri, 22 Nov 1996 11:16:45 +1030 (CST) Subject: Re: Who needs Perl? We do! Nate Williams stands accused of saying: > > But the policy is that nothing belongs in the 'src' tree unless > something else relies on it. You can get TCL via the ports (or could This devolves to "nothing belongs in the source tree". If you accept any other argument, then we are talking about what level of service/redundancy (depending on perspective) is appropriate. > main tree. I'm willing to be proven wrong, but unless that happens soon > I'm gonna stay in the 'complain and moan' camp. (I *HATE* seeing stupid > TCL man-pages that come up instead of the C routines). And finally, your real gripe. How about reordering your manpage search order so that 3 comes before n? I hate getting printf(1) before printf(3) too; do you hear me griping about that? > Nate - -- ]] 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: Terry Lambert Date: Thu, 21 Nov 1996 17:34:57 -0700 (MST) Subject: Re: Who needs Perl? We do! > > There is too much "damage control" and too little "consideration" taking > > place for an unbiased conclusion that what Richard volunteered to do > > "wasn't what needed to be done". > > Richard was completely free to do what he wanted to do, but he wasn't > going to get the 'blessing' of anyone until he had a working prototype > that was at least as good as the current system. I don't think that was the problem. What he was looking for was a commitment that, if there was consensus that the prototype was "at least as good as the current system", then the existing system would be replaced. In other words, a definition of an acceptable replacement and an agreement to not change the definition out from under him while he did the work. Then all Richard would have to do is "meet spec" instead of "meet spec and play politics". > To bring in the blast from the past, you becamse the defacto patchkit > maintainer because you did the work, not because you got Bill's (or > anyone else for that matter) permission. I was given the ugly stick > because (hopefully) I had shown to you my willingness to do the work and > by organizing and doing work *before* you handed me the baton. Not quite. I agree that the results would have been the same, whatever the motivation, if that's any consolation. 8-). Actually, it was because I'm more interested in (figuratively) framing houses than in nailing up sheetrock, spackling, and painting. After building the machine for building patchkits, I was interested in going on to build the next machine instead of running the one I built. In other words, I wanted to do systems engineering, not patchkit or release engineering. If you want to go the the "blast from the past" immediately previous to that one, I did the same thing with the FreeBSD FAQ: built a tool, and then instead of using it, went on to the next tool (the patchkit). If I'd known then what I know now, I would have spent a bit more time systems-engineering a template for volunteer organizations and a bit less time waiting for Bill to wear the mantle designed by Linus. I can only say that I was naieve about what the spirit of volunteerism can and can't motivate in the face of normal human group dynamics in the context of a private law system. I'll know better The Next Time, and will install a self-maintaining, machine-run voting democracy with a prioritization feedback loop. Example: Each person gets N "votes" in a time period, and can "spend" up to 0-K of them on any topic. Each person also gets some M << N "call for votes" that they can "spend" in a given time period. Majority rules. Votes close 4 weeks after call, or when a majority is undeniable (the number of remaining potential votes is less than the total minus the votes already cast for one side of the issue). Each accumulates over time, and both quit accumulating when they reach the limit. Same thing for organizational policy decisions, only with smaller limits to ensure a longer periodic vector, and a 3/4 majority requirement. Like vote accumulation period, initial votes for new members, expansion of the comitters list, change in majority values, etc.. So if I truly feel strongly about something, I can "call for a vote", and then "vote up to K votes" for/against. Everyone else "votes up to K votes" for/against. If they care. If they don't care enough to vote, then what they say really doesn't matter. If I'm a whiner, I quickly run out of my number of "votes/call for votes" and the activity is self-limiting. I'll either pace myself, or you can "put me down" with opposing votes each time I enter a flurry of activity. If the main participants fail to participate fully, then the system will self-correct to a different meta-stable state that excludes them, but which does not penalize their future participation. Goodbye to: Subject: Re: Re: Re: Re: Re: My patch I didn't have time to look at your patch, but I'll get to it real soon now, I promise" -- A member of the committer society Subject: No time Sorry, your changes are too large for us to be able to vet them. -- A member of the code vetting society Subject: Re: Closed developement Sorry, I just don't have time to waste on organizational issues, I'm busy coding! -- A member of the organization committe Ah, ode to fuzzy control systems! Regards, Terry Lambert terry@lambert.org - --- Any opinions in this posting are my own and not those of my present or previous employers. ------------------------------ From: Nate Williams Date: Thu, 21 Nov 1996 17:51:31 -0700 (MST) Subject: Re: Who needs Perl? We do! > > But the policy is that nothing belongs in the 'src' tree unless > > something else relies on it. You can get TCL via the ports (or could > > This devolves to "nothing belongs in the source tree". If you accept > any other argument, then we are talking about what level of > service/redundancy (depending on perspective) is appropriate. Everything in the tree has a purpose. I can't do *anything* with TCL, and nothing in the tree uses TCL. I need the compiler to rebuild myself, but I don't need TCL for *anything* (w/regards to the system). TCL alone doesn't provide anything, while ls does (it's part of the OS). I'd even throw the games out, but they are considered part of 'standard BSD' releases. > > main tree. I'm willing to be proven wrong, but unless that happens soon > > I'm gonna stay in the 'complain and moan' camp. (I *HATE* seeing stupid > > TCL man-pages that come up instead of the C routines). > > And finally, your real gripe. No, that was a 'PLUS, I also hate it' kind of gripe. Nate ------------------------------ From: Michael Smith Date: Fri, 22 Nov 1996 11:31:32 +1030 (CST) Subject: Re: Who needs Perl? We do! Nate Williams stands accused of saying: > > > > This devolves to "nothing belongs in the source tree". If you accept > > any other argument, then we are talking about what level of > > service/redundancy (depending on perspective) is appropriate. > > Everything in the tree has a purpose. I can't do *anything* with TCL, > and nothing in the tree uses TCL. I need the compiler to rebuild > myself, but I don't need TCL for *anything* (w/regards to the system). *You* may not be able to do anything with Tcl, but *I* can. *I* can't do anythying with Perl, but *other* people can. Nobody uses the entire feature set of the system; that is a given. > TCL alone doesn't provide anything, while ls does (it's part of the OS). Tcl is actually used for BMaking stuff, as you may have noticed. Jordan is bolting the new install together using it. I'm working on some configuration tools using it. 'ls' is only useful if you are a shell user, and need to see what files are on the disk. There are plenty of systems where 'ls' isn't particularly useful at all. Like I said, we're talking about a matter of degree, not principle. > No, that was a 'PLUS, I also hate it' kind of gripe. Hmm, it was the only one I could see that wasn't purely philosophical. > Nate - -- ]] 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: Nate Williams Date: Thu, 21 Nov 1996 17:58:17 -0700 (MST) Subject: Re: Who needs Perl? We do! > > > There is too much "damage control" and too little "consideration" taking > > > place for an unbiased conclusion that what Richard volunteered to do > > > "wasn't what needed to be done". > > > > Richard was completely free to do what he wanted to do, but he wasn't > > going to get the 'blessing' of anyone until he had a working prototype > > that was at least as good as the current system. > > I don't think that was the problem. That was *the* problem, and I was one of the most prolific posters. > What he was looking for was a commitment that, if there was consensus > that the prototype was "at least as good as the current system", then > the existing system would be replaced. You get that *after* you've proven your point, not before. That's the way things work. Because one person's 'solution' may meet all the technical criteria (ie; it solves the problem) doesn't mean it meets all the criteria (is this *better* than the current system). I won't buy off on *anything* simply because there is no such thing as 'completely technical' solution that have no politics/emotions/personal judgement involved. Richard may think he solution is 'easier/better/cleaner', but since I'm one of the users responsible for using it I leave it up to *MY* judgement to determine that. If he doesn't like my opinion, he can bring it up with someone else, etc... As a 'committer' I'm responsible for the code in the tree, and responsible to both users and developers. I don't take that responsibility lightly, and as such you should be commending the committers for trying to maintain some semblance of 'consistancy' in the tree rather than beating them over the head for doing their job. Nate ------------------------------ From: Nate Williams Date: Thu, 21 Nov 1996 18:07:08 -0700 (MST) Subject: Re: Who needs Perl? We do! Michael Smith writes: > Nate Williams stands accused of saying: > > > > > > This devolves to "nothing belongs in the source tree". If you accept > > > any other argument, then we are talking about what level of > > > service/redundancy (depending on perspective) is appropriate. > > > > Everything in the tree has a purpose. I can't do *anything* with TCL, > > and nothing in the tree uses TCL. I need the compiler to rebuild > > myself, but I don't need TCL for *anything* (w/regards to the system). > > *You* may not be able to do anything with Tcl, but *I* can. *I* > can't do anythying with Perl, but *other* people can. Nobody uses > the entire feature set of the system; that is a given. > > > TCL alone doesn't provide anything, while ls does (it's part of the OS). > > Tcl is actually used for BMaking stuff, as you may have noticed. > Jordan is bolting the new install together using it. I'm working on > some configuration tools using it. Let's see those tools, and then I'll shutup. Again, there are lots of *useful* things that we could bring in, but they aren't used and/or essential. Should we bring in Python as well, and what about the new Limbo compiler from the folks at Lucent (nee Bell Labs). What about the ADA compiler from the GNU folks? Where do you draw the line between 'useful to some' and 'bloat'. It was decided a *LONG* time ago that unless a utility was part of the standard BSD distribution and/or was required for the running system it shouldn't be part of the tree. 'libforms' was recently deleted since it was a 'good idea' that never came to pass. It might have been a useful tool, but *FreeBSD* doesn't use it. > 'ls' is only useful if you are a shell user, and need to see what > files are on the disk. There are plenty of systems where 'ls' isn't > particularly useful at all. Like I said, we're talking about a matter > of degree, not principle. FreeBSD is sold as a multi-user Unix system. 'ls' is required on that, and as well it's distributed as part of the 'standard BSD' tools. Nate ------------------------------ From: michael butler Date: Fri, 22 Nov 1996 12:08:09 +1100 (EST) Subject: Re: Disk Striping Jaye Mathisen writes: > Uh, by definition, isn't striping spreading the load across spindles? > I realize it's a tad more complicated than that, but the essence is the > same. This is optimally effective when there is only one locality of reference since striping then serves to reduce the number of seeks (divide number of tracks transferred by N drives) and introduce an element of parallelism into the disk transactions (each drive will detach from the SCSI bus whilst busy). > > There are four activities which consume disk resources: > > > > i) maintenance of the active and history files > > ii) maintenance of the overview hierarchy > > iii) writing out the articles themselves > > iv) scribbling to /var/log/news These activities are usually not operating on adjacent locales when implemented on a single drive (or one logical constructed out of a few physical ones). Thus the striped drive will be seeking all over the place and losing much of the advantage of striping in the first place. You do not want to design something that inherently seeks a lot, you need to minimise seeking for both performance, long term reliability and drive life. It is, however, quite valid to stripe any one activity, such as scribbling out the articles across multiple drives. You could, for example, use two striped drives for the history stuff, one for the overview (only if you have any readers) and two striped for the article spool to achieve what you're after. Even better, split the two striped arrangements onto two separate (SCSI) controllers, michael ------------------------------ From: davidn@sdev.usn.blaze.net.au (David Nugent) Date: Fri, 22 Nov 1996 12:12:44 +1100 Subject: Re: Who needs Perl? We do! Michael Smith writes: > > This is a different argument entirely... it is a complaint that the > > installation dependency process is insufficiently seamless. > > No it is _not_. Any statically-configured system is vulnerable to > variation in usage pattern; the simple intent here is to cover more of > the possible requirements in the out-of-the-box configuration in a > reasonable fashion. If this is the reason for having it, then Perl4 is no longer viable. In the real world, the only requirement it meets is being able to run the scripts with which FreeBSD is delivered, and that is far too minimal to handle "possible requirements" for using perl scripts from elsewhere, most of which are now require perl5. It needs to be removed or replaced. 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: Fri, 22 Nov 1996 11:53:27 +1030 (CST) Subject: Re: Who needs Perl? We do! Nate Williams stands accused of saying: > > > > Tcl is actually used for BMaking stuff, as you may have noticed. > > Jordan is bolting the new install together using it. I'm working on > > some configuration tools using it. > > Let's see those tools, and then I'll shutup. Again, there are lots of Sure. Right now I'm taking gripes from my employer, my SO and the DOS emulation people for the time I'm spending on my part; I don't plan on wasting all that angst. > essential. Should we bring in Python as well, and what about the new > Limbo compiler from the folks at Lucent (nee Bell Labs). What about the > ADA compiler from the GNU folks? Where do you draw the line between > 'useful to some' and 'bloat'. That is _exactly_ what this thread has been about; ref. my original post. In my opinion, the usefulness of Perl in the base system outweighs the 'bloat' consideration. I'm aware that bloat is an issue of religious importance to some people, and I've been trying to encourage one of these people (that isn't as overloaded as the rest of us 8) to do something constructive about it without alienating the "comfortable system" people by telling them to go pick a pile of ports. > It was decided a *LONG* time ago that unless a utility was part of the > standard BSD distribution and/or was required for the running system it > shouldn't be part of the tree. That's all well and good, but it presents a chicken-and-egg situation for anyone trying to work outside the decades-old BSD model. You may not consider this a problem; I do. Opinions differ. > FreeBSD is sold as a multi-user Unix system. 'ls' is required on that, > and as well it's distributed as part of the 'standard BSD' tools. I get this really sinking feeling around that whole concept. It's like there's a little stack of yellowing 15x11 half-blue tractor-feed somewhere with the Unix Commandments in faded courier on it, and that it exerts this Powerful Force over all those that have read it, hardening their hearts against anything not thought of at least ten years ago. Maybe that as it should be; I just beg to differ. > Nate - -- ]] 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: Nate Williams Date: Thu, 21 Nov 1996 18:28:42 -0700 (MST) Subject: Re: Who needs Perl? We do! > > ADA compiler from the GNU folks? Where do you draw the line between > > 'useful to some' and 'bloat'. > > That is _exactly_ what this thread has been about; ref. my original > post. In my opinion, the usefulness of Perl in the base system > outweighs the 'bloat' consideration. Agreed (to a point). > > It was decided a *LONG* time ago that unless a utility was part of the > > standard BSD distribution and/or was required for the running system it > > shouldn't be part of the tree. > > That's all well and good, but it presents a chicken-and-egg situation > for anyone trying to work outside the decades-old BSD model. You may > not consider this a problem; I do. Opinions differ. Yes, but anyone capable of developing a 'cool tool' with TCL that we can't live w/out is capable of installing a port, and *then* showing me how wonderful it is to justify bringing in TCL as part of the base system. Put the cart *before* the horse. Nate ------------------------------ End of hackers-digest V1 #1667 ******************************