Re: recent apm changes

> plm> In contract, if I suspend in Linux of Windows, the computer shuts up > plm> immediateley and is quiet. Only sometimes there is a (not too loud) > plm> little fan (I think it is the CPU fan) running for a few more minutes. > > I've read Linux code (v2.2.9) closely, noticed they put cli > b

Re: recent apm changes

> > As far as the segment registers, we do an explicit save of them already > > when we switch into VM86 mode, so it should be necessary to save them > > twice. > > VM86 mode is only used to enable APM; after that we are using the > 32-bit protected mode interface. Ahh... In the old code, we u

Re: it's time...

> : Correct, but the nature of the kernel probe/attach messages is to convey > : information in a readable, consistent, useful manner. > > Agreed. However, what's magical about 80 columns? What's magical is that almost every text console is limited to 80 columns (think serial console), as well

Re: it's time...

> : The line wrapping stuff I brought back for the EISA bus stuff in -current > : makes it easy to define the wrap point. If some small number of people > : want the ability to wrap at 132 or 40 or whatever, I don't think its > : unreasonable to provide them the knob to tweak in the boot loader.

Re: it's time...

> : stty columns is only effective *AFTER* you have a shell and the box has > : booted. > > Yes I know that, but you seem to be arguing that all terminals have 80 > columns... This is not the case, although many of them do. Most of them do. It is the 'least common denominator' that FreeBSD run

Re: recent apm changes

> APM Spec. v1.2 Appendix D - APM Driver Considerations - FWIW, the wording here is almost the same as the previous specifications. > When an APM connection exists, the APM BIOS transitions into System > Standby and System Suspend states only when directed to do so by a > call from the APM D

Re: IBM ThinkPad 600E with cardbus EtherJet 10/100 :)

> 1: any access to the serial port (/dev/cuaa0) locks the machine. Weird. I haven't tried accessing mine though, but I know there are lots of weird setup issues that must be done to get the serial port to be read correctly. > 2: I cannot get the ethernet card to work. > 2a: It is sort-a recog

Re: ** HEADS UP ** chown&chgrp moved again

> This week, I have added chown-like functionality to mknod(8) and restored > chown & chgrp back to their previous locations. MAKEDEV has been > updated to use the new functionality of mknod(8). Thanks for doing this David! Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscri

Re: ipfw optimizations

> > One of the things I would do to optimize ipfw is: > > - instead of keeping one list with all the rules, split the list (the > > internal one) by interface and by direction (one list for ed1 incoming, > > one list for ed1 outgoing, etc.). > > one skipto rule is enough to switch between two

RE: load spike strangeness

[ Moved to chat ] > [Multiple irrelevant mailing-lists snipped.] > > < said: > > > Since when does an E-mail address require a "realname"? > > As Sherlock Holmes once said: ``It is always unpleasant dealing with > an alias.'' > > >plonk< Boo... Hisss Nate ;) ;) ;) ;) ;) ;) ;) ;) ;) ;)

Re: NTP4 manual pages committed

> Those of you who whined about the absence of manual pages in the NTP4 > package recently imported into the base system, please check your commit > mail. Thanks Sheldon! Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: SIO "lost interrupt" status in current?

> I'm actually pretty sure it happens even without X11 live. This worries me! > changing the modem serial speed down from 57600 through 33600 to 19200 made > no difference. This also worries me. If the speed isn't being set down, then somehow interrupts are being turned off for a very long time,

Re: SIO "lost interrupt" status in current?

> > I'm actually pretty sure it happens even without X11 live. This worries m > e! > > changing the modem serial speed down from 57600 through 33600 to 19200 ma > de > > no difference. This also worries me. > > If the speed isn't being set down, then somehow interrupts are being >

Re: followup to apm problems.

> : And it seems there still are other devices which wake your PC up in > : 2-3 mins time. > : Hmmm, anyone has ideas? > > I think we need to set the interrupt mask to 0 in the PIC. I don't think makes any difference, since the APM Bios is in charge of what happens at this point, and the BIOS is

Re: start xdm on a particular vty

> There have been discussions about the xdm entry /etc/ttys does not guarantee > the X server being started on the particular vty. So I wrote a shell script > to explicitly tell xdm to start X server on a specific vty. I *like* it. I think you should share it with the XFree86 folks, and I think

Re: start xdm on a particular vty

>>> There have been discussions about the xdm entry /etc/ttys does not >>> guarantee the X server being started on the particular vty. So I >>> wrote a shell script to explicitly tell xdm to start X server on a >>> specific vty. >> >> I *like* it. I think you should share it with the XFree86 fol

Re: start xdm on a particular vty

> > Do you know the appropriate channel to contact the XFree86 folks? In the > > mean while, I can take Sheldon's advice, submit it to our XFree86 port. > > By the way, I've just thought of something you should consider. I think > there's still a problem with xdm, where trying to change vty while

RE: java too? (was Re: Perl still broken in 4.0-CURRENT)

> > I think that java is still broken by this. > > .. > >> java > > Segmentation fault (core dumped) > >> > > I've just committed the fix in "src/libexec/rtld-elf/rtld.h" revision > 1.12. The Java runtime was peeking into some of the dynamic linker's > private data structures. My recent change

RE: java too? (was Re: Perl still broken in 4.0-CURRENT)

> > This is necessary because the JDK has no way of knowing if dladdr() and > > other misc. functions exist at runtime, because it must run on *all* > > versions of FreeBSD, and older versions of 3.* didn't have these > > functions. > > > > We can't maintain backward compatability 'cleanly' w/out

RE: java too? (was Re: Perl still broken in 4.0-CURRENT)

> OK, sorry for the delay. Here's what I'd recommend for Java: Thanks for the hints. I've forwarded them onto the developer mailing list, and will respond to you with any comments he has. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of

Re: ccd build failure

> :[Insert semi-nasty message about how people should really be testing > :their changes before they commit, how it is a blatant disregard for > :basic human rigths not to do so etc etc etc] > ... > Insert nasty message about how people shouldn't post idiotic comments. Play nice boys! Reme

Re: On hub.freebsd.org refusing to talk to dialups

> > I agree. > > > > > Your work also has a serious security concern if it allows this you to > > > directly attatch to it's port 25. > > > > No it doesn't, but you do bring up another good point why not to use the > > ISP's mail server. Security. I don't want email to bounce on your box > > a

Re: On hub.freebsd.org refusing to talk to dialups

> > would immediately unsubscribe to any isp that decided this was acceptable > > behavior on their part. I agree. > Your work also has a serious security concern if it allows this you to > directly attatch to it's port 25. No it doesn't, but you do bring up another good point why not to use t

Re: HEADS UP: sigset_t changes committed

> I just finished committing the sigset_t changes I worked on for the last > 5 weeks. Thanks Marcel, this was great, and the commit messages were outstanding (as well as humorous :). Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the mes

Re: HEADS UP: sigset_t changes committed

> Following up on my previous mail regarding the panic on the Alpha, > I've been looking at the diff for the code in question, in > "src/sys/nfs/nfs_socket.c": > > @@ -1501,14 +1502,16 @@ > struct nfsreq *rep; > register struct proc *p; > { > + sigset_t tmpset; > > +

Re: HEADS UP: sigset_t changes committed

> Nate Williams wrote: > >> Following up on my previous mail regarding the panic on the Alpha, > >> I've been looking at the diff for the code in question, in > >> "src/sys/nfs/nfs_socket.c": > >> > >> @@ -1501,14 +1502,16 @@ > &

Re: Now that sigcontext is gone ...

> I'm trying to digest the recent signal changes and get a handle on > what I need to do to make Modula-3 work. There is code in the runtime > currently which catches SIGBUS and uses the sigcontext's "sc_err" > member to find out the faulting address. That should be replaced > by the siginfo_t's

Re: new sigset_t and upgrading: a proposal

> > Mainly historical bugs. Includes are installed too early and they only > > match the new syscalls. Tools are built using the new includes, so they > > need new libraries to be consistent. Therefore the new libraries are > > built before the new tools. These bugs were implemented in FreeBSD

Re: HEADS UP: sigset_t changes committed

> you don't under stand, we are NOT talking about upgrades, we are talking > about how to make a buildable system on -stable... There are essentially the same problem. In order to do an upgrade, you have to be able to build on -stable. :) > ===> libgcc > echo '#include ' > config.h > echo '#in

Re: HEADS UP: sigset_t changes committed

> P.S. It is really hard for me to not make personal attacks against you > after all of the above and completely ignoring the rest of my message. No, I didn't. My statement was that your 'confrontational' style of email wasn't making things any better. Mellow it out, and instead of attacking fi

Re: Now that sigcontext is gone ...

> > Sigcontext will have to come back, since it is a standard BSD interface. > > I think so too. I bet there are several ports besides Modula-3 that > use it. Probably boehm-gc does. The JDK does as well, at least for the green-threads stuff. Nate To Unsubscribe: send mail to [EMAIL PROTE

Re: sigset_t: a summary

> 1. Should the ucontext_t changes be backed out, or is this the >way we would like to go? (but only it better :-) We need something. Rather than say 'something better', I'd need to see what that better things is. However, given Bruce's comments earlier, it seems like we need to have uconte

Re: make install trick

> In any case, you should not be doing lots of writes to root, so the > lack of softupdates should not be a problem. So, are you suggesting make /tmp it's own disk, otherwise anytime you do development alot of writes are done to /. And, if you do lots of development, then you'll have the same pr

Re: The eventual fate of BLOCK devices.

> I Can't believe this email only produced TWO responses! > I would have thought that this wouldhav brought out the chainsaws! > Maybe no-one is listenning on 'arch' any more, or maybe 'arch' doesn't > work? (the only responders got it via 'core') Interesting. It appears that somehow I got 'unsu

Re: People getting automatically unsub'ed from -arch

> > > > Maybe no-one is listenning on 'arch' any more, or maybe 'arch' doesn't > > > > work? (the only responders got it via 'core') > > > > > > Interesting. It appears that somehow I got 'unsubscribed' from arch. > > > Not sure why, but in May I was subscribed, but I'm no longer subscribed. > >

Re: People getting automatically unsub'ed from -arch

> [Mayhaps too many Cc:'s kept in order to reach relevant audience] Thanks, sorry about the X-posting... > On Sun, Oct 10, 1999 at 02:57:55PM -0600, Nate Williams wrote: > > > I Can't believe this email only produced TWO responses! > > > I would have thought

Re: People getting automatically unsub'ed from -arch

> > "Accidental" removals from the lists are so common that I give up. I no > > longer even try to get back on them -- it's been happening for _years_ now, > > and I have made multiple complaints about it, and if it's not a problem for > > whoever runs the mailing lists, then I just don't care th

Re: GENERIC build broken

> I think most if not all the ethernet cards I or my customers > have bought over the last year have sported mighty fine netboot > capabilities. FWIW, few of the cards I've bought over the years sport netboot. And, netboot is an impossibility in 'embedded' systems that use things like PCMCIA/CAR

Re: GENERIC build broken

> > > I think most if not all the ethernet cards I or my customers > > > have bought over the last year have sported mighty fine netboot > > > capabilities. > > > > FWIW, few of the cards I've bought over the years sport netboot. And, > > netboot is an impossibility in 'embedded' systems that us

Re: Java segfaulting

> I'm running -current as of 9:00 CDT October 30, and ever since I rebuilt, I > have not been able to run any Java applications. All of them exit with > the following error output: Running Java on -current is at best a hit-miss operation, simply because we were forced to hard-code in some linker

Re: gzip(1) hanging

> I've got a -current box freshly CVSup'd and built from last > night that is exhibiting some rather bizarre behavior. I > actually noticed the problem on my Alpha package building > machine, but the same behavior exists on my i386 box. > > To see what I'm seeing (or maybe not :) all you have to

Re: need patch review - NFS fixes for IP binding

> Instead, I have adopted and cleaned up the kernel portions of the patch > and modified nfsd to allow the binding ip/host to be specified on the > command line. Thus nfsd can be run bound to a specific IP address. This sounds like a great solution, thanks Matt! Nate To Unsubscri

Re: HEADS UP, bind update shortly...

> I'm about to import bind 8.2.2.p5 into src/contrib/bind and fix up the > broken parts of the tree as I go. I will disable the named (and associated > tools) build for the duration. If you want to do some make worlds or > releases in the next 8 hours or so, do a cvsup pronto! Thanks Peter! N

Re: HEADSUP: wd driver will be retired!

> In a few days time the wd driver will be retired from FreeBSDs > i386 architecture. Given that the ATA driver just went active a few minutes ago, I think a period of shakeout time would be called for. I think that time should be longer than a few days, and should be in 4.0, and then retired in

Re: HEADSUP: wd driver will be retired!

> What we need here is a commitment to these new initiatives, not a lot of > fence-sitting and clutching our knitting to our chests. If all our users were developers I would agree. But *most* of our users are not developers. > Again, I say, think of what we're trying to achieve here. Good que

Re: HEADSUP: wd driver will be retired!

> In message <[EMAIL PROTECTED]>, Nate Williams writes: > >> What we need here is a commitment to these new initiatives, not a lot of > >> fence-sitting and clutching our knitting to our chests. > > > >If all our users were developers I would agree. But *m

Re: HEADSUP: wd driver will be retired!

> >> In a few days time the wd driver will be retired from FreeBSDs > >> i386 architecture. > > > >Given that the ATA driver just went active a few minutes ago, I think a > >period of shakeout time would be called for. I think that time should > >be longer than a few days, and should be in 4.0, a

Re: HEADSUP: wd driver will be retired!

> What is a killer is if a large number of people on popular hardware can't > even boot, *at all*, in no, way, shape or form. Only that. The only way > to find that out for sure before 4.0 is to push the issue *now*. I disagree, but I'm not making the decision. Nate To Unsubscribe: send mai

Re: HEADSUP: wd driver will be retired!

> >> >> In a few days time the wd driver will be retired from FreeBSDs > >> >> i386 architecture. > >> > > >> >Given that the ATA driver just went active a few minutes ago, I think a > >> >period of shakeout time would be called for. I think that time should > >> >be longer than a few days, and s

Re: HEADSUP: wd driver will be retired!

> If half as much energy was spent adding the missing bits of functionality > to the new systems as people have been spending complaining it then we'd be > there ages ago. Not true. It doesn't take a disk expert to complain about a policy, but it takes one to fix bugs/add features to the existin

Re: HEADSUP: wd driver will be retired!

>>> If half as much energy was spent adding the missing bits of >>> functionality to the new systems as people have been spending >>> complaining it then we'd be there ages ago. >> >> Not true. It doesn't take a disk expert to complain about a policy, >> but it takes one to fix bugs/add features

Re: Serious server-side NFS problem

> In message <[EMAIL PROTECTED]>, Kevin Day writes: > > >Ack, I was using this very same thing for several devices in an isolated > >peer-to-peer network to decide who the 'master' was. (Whoever had been up > >longest knew more about the state of the network) Having this change could > >cause wei

Re: HEADSUP: ntp4 to replace xntpd

> Between the two of us Dave Mills and I have managed to get the > "nanokernel" to act sensibly in the domain inside +/- 1usec which > the old one didn't. (See http://gps.freebsd.dk for what kind of > performance this can result in, given appropriate hardware). You may not know the answer to thi

Re: HEADSUP: ntp4 to replace xntpd

> : You may not know the answer to this, but it's worth a shot. Wht kind of > : accuracy can we expect using 'cheap' off-the-shelf GPS receivers? > > We're getting, with ntp4 on a 3.x kernel, about +- 4uSec with a cheap > gps receiver + atomic clock on a i486 class machine. I've got the cheap g

Re: Serious server-side NFS problem

> : If people do a "settimeofday" we change the boot time since the > : amount of time we've been up *IS* known for sure, whereas the boottime > : is only an estimate. > > There is one problem with this. The amount of uptime isn't the same > as the amount of time since the machine booted. How c

Re: HEADSUP: ntp4 to replace xntpd

> : > : You may not know the answer to this, but it's worth a shot. Wht kind of > : > : accuracy can we expect using 'cheap' off-the-shelf GPS receivers? > : > > : > We're getting, with ntp4 on a 3.x kernel, about +- 4uSec with a cheap > : > gps receiver + atomic clock on a i486 class machine. >

Re: HEADSUP: ntp4 to replace xntpd

> : Cool. I was under the impression that the cheap NMEA signals only gave > : 2-5sec accuracy given the 2400 baud speed issues. > > If you have a PPS signal, then you can get fairly close even if the > inforation about the PPS signal comes in at 2400 baud. Hmm, how do I find out how good it is

Re: HEADSUP: ntp4 to replace xntpd

> >> Between the two of us Dave Mills and I have managed to get the > >> "nanokernel" to act sensibly in the domain inside +/- 1usec which > >> the old one didn't. (See http://gps.freebsd.dk for what kind of > >> performance this can result in, given appropriate hardware). > > > >You may not know

Re: PCCARD vs GENERIC

> PCCARD used to exist separate from GENERIC due to the zp and ze > drivers not being compatible with pccard's pcic driver. These drivers > were removed from the system not too long ago by phk. The reason I added PCCARD to the system was because in the old code, I didn't trust the PCCARD functio

Re: PCCARD vs GENERIC

> : So, my only comment is that if you believe that the code is stable > : enough to not negatively effect desktop systems, and not too much bloat, > : then have at it. Note, enabling PCCARD functionality w/out APM will be > : a losing situation for many laptops, and adding APM functionality for

Re: problem with reboot on 5.0-current with VAIO

> When I use reboot(8) to reboot my Vaio z505sx, it waits nicely for > the bufdaeon and the syncer to stop. Then the screen goes blank > and the system completely hangs. Unplugging the battery and power > is the only way to gte it booting again. It used to work fine with a > 4.0-current of some 3

Re: Is there spinlocks/semaphores available for drivers?

> :> *not* preempted except when being interrupted, so there are no > :> 'priorities', per say. Or, rather, the relative priority is strictly > :> that the interrupt takes priority over supervisor code except when > :> disabled by said supervisor code. > : > :But locks with owners

Re: Is there spinlocks/semaphores available for drivers?

> :> :> *not* preempted except when being interrupted, so there are no > :> :> 'priorities', per say. Or, rather, the relative priority is strictly > :> :> that the interrupt takes priority over supervisor code except when > :> :> disabled by said supervisor code. > :> : > :> :But

Re: Is there spinlocks/semaphores available for drivers?

> :And would there still be areas of the kernel that disable multiple > :interrupts, perhaps CAM or the network stack for instance? What do > :all the splbio and splnet calls translate into in this new scheme? > : > > The entire design of the kernel is currently predicated on the spl*() >

Re: signal mask from jmp_buf

> > What is the proper way for obtaining the signal mask from > > within the jmp_buf struct on 4.x or -current? Previously > > with the JDK port for < 3.x we did something like this: > > > > signalMask = jmpbuf[0]._sjb[6]; > > > > This no longer works now that we support >32 signals. I

Re: Problems with MAKEDEV.

> > >That's always struck me a bit odd... I thought 'MAKEDEV std' made > > >the generic set of devices and that 'MAKEDEV all' should make... well.. > > >_ALL_. *shrug* > > > > What do you define as `all'? Say I have a big FTP server with 8 wide > > SCSI controllers, each with 15 disks - that's d

Re: FreeBSD Build status

> >: awi.o(.text+0x3b4): undefined reference to `memcmp' > >: awi.o(.text+0x3cf): undefined reference to `memset' > > > >What I want to know is why I don't get these with the GENERIC + awi > >config file I have :-( Are you compiling with optimization turned on? I believe mem* are inlined if opti

Re: FreeBSD Build status

> : Are you compiling with optimization turned on? I believe mem* are > : inlined if optimization is enabled. > > Don't think so. Both build -O. Poul's build may not have optimization turned on, since it's controlled by /etc/make.conf. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] w

Re: FreeBSD Build status

> : > : Are you compiling with optimization turned on? I believe mem* are > : > : inlined if optimization is enabled. > : > > : > Don't think so. Both build -O. > : > : Poul's build may not have optimization turned on, since it's controlled > : by /etc/make.conf. > > It isn't something specif

Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

> >Core should consider reverting the special rules that were originally > >created with the expectation of major breakage in 5.x back to > >the set of rules we had for 3.x and 4.x. > > I have no idea what special rules you are talking about for 4.x/5.x. > > 4.x-stable is a -stable

Re: Archive pruning

> I want to bring up a suggestion. I just want a little bit of argument on > it ... and if you're violently opposed, just say so, that's fine. > > I want to suggest that, once a year, we go thru the cvs archive, and prune > away all history more than 3 (or maybe 2, maybe 4) years old. I'm violen

Re: Archive pruning

> On Mon, 24 Apr 2000, Nate Williams wrote: > > I'm violently opposed to removing it completely. The only thing I > > wouldn't be violently opposed to would be removing 'Attic' files (truly > > unused file), and having them stored away somewhere in the

Re: Archive pruning

> > I'd like to add that it can be particularly important when legal > > questions arise. > > You confuse the argument for SOME complete repositories with > the necessity that ALL (or at each most) repositories be so extensive. No-one needs to grab a repository, unless they're looking at histor

Re: asm_pci.h,v Holy cow!

> > If that's the _only_ point, then Garrett Wollman's idea should work > > perfectly. Stick the files under CVS > > No, that was not my proposal. I want to keep them out of CVS > entirely. CVS is Not Good at handling binary files (even if you never > change them). That's why I'd like them in

Re: Archive pruning

> > No-one needs to grab a repository, unless they're looking at history. > > Just use CVSup to grab the latest bits, no need to grab the entire > > history. > > I find it virtually impossible to work with anything but the most stable > without the recent part of the repository because I often h

Re: db 1.85 --> 2.x or 3.x?

> > Sleepycats license is not FreeBSD compatible :-/ > > I don't understand. Reading > , it seems to me that FreeBSD > meets all the necessary requirements. Can someone who understands > the details of the licensing issues either explain the situa

Re: HEADS UP: loader and libstand caution required.

> Please be sure that you build and install libstand before building > a loader! (or use buildworld, that should work) Good job tracking this one down Peter Nate > > FICL is now active on the Alpha, and actually seems to work. The Alpha > problems have been solved - it was an alignment

Re: Motif is now Open Source 8)

> Check it out at: > http://www.opengroup.org/openmotif/ > > "We want to support the momentum of Open Source operating systems such as > Linux® and FreeBSD by developing an Open Motif® licence for use with > Open Source operating systems." > > Also the OpenGroup is looking for sites to mirror t

Re: Motif is now Open Source 8)

> > I have a copy. However, the license is 'interesting' enough to read > > that I'm not sure it can be used inside the JDK distribution, so if > > someone can give me an explanation that I can understand that I'm legal > > to distribute the library as part of an application, please show me in >

Re: Motif is now Open Source 8)

> > > I think that you no longer have to include Motif with the JDK. > > > Just let the distribution of Motif come from freebsd.org , i.e., > > > a port or a package. > > > >Too much hassle IMO. I'd *much* rather distribute it as part of the > >package, and I'm looking into how feasible it would

Re: Motif is now Open Source 8)

> > > If this Open Motif can be distributed as a port or package for FreeBSD > > > itself (and it seems to me that it can), then what hassle is that for > > > JDK on FreeBSD? > > > >It requires two downloads to get a working JDK system. No other OS > >requires multiple packages to work. > > As l

Re: Motif is now Open Source 8)

> >Unlike X (which rarely changes), I suspect the Motif stuff to change > >alot. > > I'm unclear on what gyrations you are expecting from a mature API > codified in an IEEE standard. As long as you're using the Motif > standard interface in your code you should have nothing to worry about. Ahh,

Re: Motif is now Open Source 8)

> > It requires two downloads to get a working JDK system. No other OS > > requires multiple packages to work. > > > > People shouldn't have to compile Motif up just to get a non-source > > version of the JDK to work. Versioning problems that can be caused by > > folks using different include f

Re: Anyone else seeing jumpy mice?

> No, I don't mean rodents who've nibbled on chocolate-covered expresso > beans, I mean PS/2 mice which fall victim to this new problem: > > May 19 00:50:45 zippy /kernel: psmintr: out of sync (00c0 != ). > > I've seen it for the last few weeks and can only think that something > must be sto

Re: Ugly, slow shutdown

> It's not just that, if you always have to cover your behind when > doing tsleep you may wind up masking wakeup bugs. Places like > "vfs_bio.c" line 586 of 3182: > > bp->b_xflags |= BX_BKGRDWAIT; > tsleep(&bp->b_xflags, PRIBIO, "biord", 0); > if (bp->b_

Re: make buildworld br0ken in libutil

> > >> Alternatively the sentiment just rose why we couldn't just collapse the > > >> crypt/hash functions of libcrypt into libc. > > >> > > >> It would make sense. > > > > > >It would make even make more sense to convince the other BSD to do the same > > >(haven't checked recently what they do) a

Re: HEADSUP!!!! KSE Milestone-2 COMMITTED

Congratulations Julian, and thanks for all the hard work to you and the rest of the folks! Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: uucp user shell and home directory

> All these "solutions" assume that everyone is wired up with IP > connectivity. The original questions was "who uses UUCP?" Correct. > One answer is: "those without IP connectivity." Do you mean 'full-time IP connectivity', because if you can setup a UUCP connection, you can just as easily set

Re: uucp user shell and home directory

> > > POP and IMAP (I think) will lose all the envelope information, > > > > You've been listening to Terry too long. It's certainly not the case, > > although I've decided to quit arguing with Terry, since it's an > > excercise in futility. No matter what you say, he'll either change the > > s

Re: uucp user shell and home directory

> Interestingly, Microsoft Exchange is one of the few commercial > SMTP servers that can handle more than a few hundred ETRN based > virtual domain instances. Go figure... Any Q-Mail based solution using the commonly available ETRN patch also scales well, although you have to 'roll your own' rel

Re: uucp user shell and home directory

> POP and IMAP (I think) will lose all the envelope information, You've been listening to Terry too long. It's certainly not the case, although I've decided to quit arguing with Terry, since it's an excercise in futility. No matter what you say, he'll either change the subject or simply overwhe

Re: uucp user shell and home directory

> > I don't get your point - what is wrong with having it a port? > > Well, here's one reason: > > 1) Remove all the network interfaces from your system (Ethernet, > PPP, SL/IP, etc). > > 2) cd into /usr/ports and try to build UUCP. > > Unless you have a prepopulated /usr/ports/distfiles, it

Re: gcc3.x issues

> : How many MB does your flash card where you're installing > : FreeBSD have on it? > > I've installed a subsetted FreeBSD onto a 8MB CF card. For normal > FreeBSD (as oppsoed to pico), the smallest amount of space you need is > about 6.9M, and that can be stripped down to about 5M with compres

RE: BESTDEB: your Postfix installation is hosed

> > You are reflecting messages back to a mailing list with > > thousands of subscribers. > > > > Cut it out. > > > > -- Terry > > Peter has applied the Big Hammer of Death to the problem for now, so > it should be stopping soon if not already. Thanks Peter Nate To Unsubscribe: send ma

Re: ipfw: several equal rules under same number bug

> How it can be possible? ipfw -a l: > > 07001 401680 deny tcp from any to any 7006 > 070010 0 deny tcp from any to any 7006 > 070010 0 deny tcp from any to any 7006 > > I use equal "ipfw add" several times from the script, but the rule number >

Re: lockup after resume

> > One surprising observation: If I disable APM in /boot/device.hints, my > > machine suspends and resumes JUST FINE. The BIOS alone seems to be > > able to suspend and awake the hardware behind FreeBSD's back. The > > system only hangs if FreeBSD is involved in the process. > > Hmm, I might t

Re: bash in /usr/local/bin?

> > # Bash has a license which precludes its inclusion as part > > # of the base system. > > > > [Not that I favor more shells on the root file system, but anyway:] > > What about gcc and grep? Does the license differ or are these not regarded > > being part of the base system? > > We would get

Re: bash in /usr/local/bin?

> I said I'd drop it, but apparently there are people that don't > understand the dinosaur mentality of certain organizations such as > DOD, DISA/DECC, OSD, DARPA, USA, USN, USAF, and USMC. > If it's not in the base setup, on a production box, you can't use it. *Huh* This policy must have b

Re: Copyright Contradiction in libalias

> If you ever claimed to hold the copyright to software that has been > released into the public domain, you would be commiting fraud. Not if I'm the author of the software. I can release my software under as many licenses as I'd like, including putting it into the public domain. However, I can

Re: Copyright Contradiction in libalias

> | > If you ever claimed to hold the copyright to software that has been > | > released into the public domain, you would be commiting fraud. > | > | Not if I'm the author of the software. > | > | I can release my software under as many licenses as I'd like, including > | putting it into the pu

  1   2   >