Re: __fpclassifyd problem

[ add compatability hacks to libm ] > > We tried this at usenix, but it still didn't work. Obviously there is more > > going on. > > > > Before anybody goes and bumps libraries etc, it would be useful to know if > > running a statically linked jvm will work on -current. > > This sounds like a go

Re: sendmail: no local mailer

> > > evantd> Sendmail has not been working on my system for some time now. I > > > evantd> can't say exactly how long, but my guess is that it broke when I > > > evantd> upgraded to RELENG_5_0. This is how sendmail is invoked (by > > > evantd> default) and it's output. > > > > > > evantd> # sendm

Re: sendmail: no local mailer

> evantd> Sendmail has not been working on my system for some time now. I > evantd> can't say exactly how long, but my guess is that it broke when I > evantd> upgraded to RELENG_5_0. This is how sendmail is invoked (by > evantd> default) and it's output. > > evantd> # sendmail -L sm-mta -bd -q30m

Re: libthr and 1:1 threading.

> > You should notice marked interactivity and UI latency improvements with > > threaded GUI apps over libc_r because GUI threads will generally no longer > > be blocked when disk I/O and blocking I/O occurs. For example, > > applications like Open Office, Netscape, et al, really get a lot better

Re: Cordless Keyboard + Mouse

> > > Has anyone been able to get the Logitech Cordless Elite Duo, or any > > > cordless kb/mouse combos to work? > > > > I've got the older Logitech 'Natural' wireless keyboard + wireless mouse > > working fine. I've had it for almost 3 years now, and aside from having > > to change batteries ev

Re: Cordless Keyboard + Mouse

> Has anyone been able to get the Logitech Cordless Elite Duo, or any > cordless kb/mouse combos to work? I've got the older Logitech 'Natural' wireless keyboard + wireless mouse working fine. I've had it for almost 3 years now, and aside from having to change batteries every 4-6 months it's been

Re: Poweroff problem with IBM ThinkPad T21 (ACPI?)

> I just put 5.0-DP2 on my IBM ThinkPad T21 (which I can finaly use, 4.x > was pretty bad since only one of the two pcmcia slots worked, and > numerous other problems, forcing me to use windows) and have been very > very happy with it. Really? I ran 4.X on my T21 for over a year with no problems

Re: [PATCH] Workaround for bogus INT 12H BIOS serviceimplementation

> I've recalled that FreeBSD used RTC to determine base memory size in > old days. I've tested this method on my machines and confirmed it's > working well. If this is done, then FreeBSD won't work on many laptops and other desktops, which report 640K for memory, but the BIOS actually steals some

Re: devfs oddity?

> >> > In message <[EMAIL PROTECTED]>, Steve Kargl w > >> > rites: > >> > >root[208] cdcontrol play > >> > >cdcontrol: no CD device name specified, defaulting to /dev/cd0c > >> > >cdcontrol: /dev/cd0cc: No such file or directory > >> > > > >> > >Why is an extra "c" appended to cd0c? > > > >The fir

Re: HEADS UP: UCONSOLE option has been phased out

> > However, it was required for some X applications to work correctly, > > which is why it was still being used. > > No, it's just required for them to work when run by unprivileged > users. Things like xconsole *are* run by unprivileged users. Nate To Unsubscribe: send mail to [EMAIL PROTE

Re: HEADS UP: UCONSOLE option has been phased out

> This is a JFYI that the UCONSOLE kernel option has been phased > out as insecure. Fix your configs. Umm, it's listed as insecure in the every config file, so you're not saying anything that wasn't already known. However, it was required for some X applications to work correctly, which is why

Re: The sendmail discussion...

> > (my company demands > > that all software I write, including in my own free time, is copyright by > > them) > > You need to move to California, where this is against the law. Every California company I've worked for has made me sign a statement with the above stipulation. In order to avoid

Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )

> > "Bruce A. Mah" <[EMAIL PROTECTED]> writes: > > > Differences of opinion on naming aside...the branch isn't supposed to > > > last long at all. The point is to provide a slightly polished snapshot > > > to the wider developer community. We can't do the QA/releng work on > > > HEAD without cal

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: 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: 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: 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

> 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 > > s

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: 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: exec issue in tcsh?

> >>> Wow. Why not use xdm? 8) > > >>Too lazy? > > >Heh. You just uncomment one line in /etc/ttys and HUP init. It's not > >compilicated. > > Indeed. However, there are some differences in startup of which to be > aware (.xinitrc vs. .xsession). I just hard-link the two files together. :)

Re: Copyright Contradiction in libalias

> : On that released version, yes. But, not on subsuquent versions. I > : still maintain my rights to do with the code as I please. > > Then you are creating a new work, based on the public domain work that > went before it. I think we're splitting hairs here. Ultimately, the exact same behav

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

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: 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: 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: 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: 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: entropy bikesheds

> Can we decide this, please - do we want secure startup (which will > take some effort to achieve), or can we say "screw it" and start > insecure like the old system? Can we have both? Ie; by default we are insecure until some point we call an ioctl() that says 'no more, you must get real rando

Re: make release still broken...

> > ===> rpcsvc > > rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h > > rpcgen: cannot find any C preprocessor (cpp) > > *** Error code 1 > > > Let me start a release. This means rpcgen has been using > /usr/libexec/cpp which is *only* for the compiler's use. rpcgen s

Re: weird cvs update problem

> > > > U crypto/kerberosIV/appl/bsd/login_fbtab.c > > > > U crypto/kerberosIV/appl/bsd/osfc2.c > > > > U crypto/kerberosIV/appl/bsd/pathnames.h_ > > > > U crypto/kerberosIV/appl/bsd/rcmd_util.c > > > > cvs update: warning: unrecognized response ` If there are any IP options on >`sock', die.' fro

Re: Fixing a.out compatibility

> It seems feasable to generate a new binary on a recent or an old patched > FreeBSD version. The question is which is better. I think the newer > the better. Otherwise, who is going to build the 2.2.8-stable box > to make this one binary? I've already built a binary on 4.2-release > that work

Re: /usr/local abuse

> David hands Nate a freshly minted copy of BSD/OS 4.2, where he will see > /usr/contrib/ burned on the CDROM (using an electron microscope of > course :-)). > > > Even Sun does this with it's 'OS vendor' tools. > > Uhm.. not everything. Many optional pieces from Sun installs in /opt. > The Sun

Re: /usr/local abuse

> > : I know that as recent as 3=4 years ago, Purify installed itself by > > : default in /usr/local, on SunOS and Solaris. Lucid did this as well, > > : although things start getting pretty fuzzy going back that far. :) > > purify and the binary distributions of xemacs installed themselves > > i

Re: Confusing error messages from shell image activation

> > Fixing broken things is a good thing. Your argument about 'moving it > > from /usr/local to show how broken' is a good test procedure, but turning > > it into policy is something completely different. > > > > I think the 'tradition' of FreeBSD installing packages in /usr/local is > > enough

Re: Confusing error messages from shell image activation

> > I ran mostly DEC boxes until the early 90s, which had all software > > installed in /usr/bin or /usr/local/bin. > > Well, I ran DEC boxes for Dec (at WSE) back in the late 80s and early > 90s, and don't remember anything being in /usr/local that I didn't > drag of the net (or write myself) an

Re: Confusing error messages from shell image activation

> > > I'm aware that software was installing itself in /usr/local years > > > before it was installing in /opt. On the other hand, vendor software > > > was installing in /opt years before I ever saw it install in > > > /usr/local. > > Most vendor software I know pre-dates /opt, and installed itse

Re: /usr/local abuse

> Then again, your quoting of "packages" points up something else - I > never saw prepackaged binaries for v6 or v7. I did on SysIII. As a matter of fact, the entire distribution was bundled into separate packets (all of them installed in /usr). :( > Or BSD, for that matter. I never encounterd

Re: Confusing error messages from shell image activation

> I'm aware that software was installing itself in /usr/local years > before it was installing in /opt. On the other hand, vendor software > was installing in /opt years before I ever saw it install in > /usr/local. Most vendor software I know pre-dates /opt, and installed itself in /usr/local.

Re: Laptops and sc0/vt0 consoles

> > Apologies upfront if anything I ask/say has already been covered, I'm > somwhat limited in my resources at present. > > In my past experience, FreeBSD hasn't agreed very well with IBM > thinkpad laptops, unless you were using the vt0 console driver. This is *VERY* old information. When Pen

Re: Cardbus fixes

> >I'll have to look up the CIS_PTR spec. I'm not sure I like hardwiring > >things like this. > > Where did you get a copy of the pccard spec? Do you have to order > it from the pcmcia SIG? Mike has my really old copy you can have (if you can get it from him), and I think FreeBSD Inc. bought W

Re: ssh and scp fail connecting to a root account

[ OpenSSH failure with particular malloc.conf flags ] > Got it ! > > See version 1.6 of src/lib/libc/stdlib/setenv.c. This took me all > night - Up for work in two hours !!! :-( Good catch! Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body

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: 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: 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: 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: 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)

> > > 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)

> > > 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)

> > 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)

> 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: 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: 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: 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: 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

> > 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: 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 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: 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: 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: 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

> >: 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: 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: 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: 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: 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?

> :> *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: 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: 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: 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: 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: ** 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: 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: 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: 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: 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

> : > : 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: 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. I've got the cheap g

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: 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: 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: 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!

> >> >> 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!

> 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 should be in 4.0, a

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!

> 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 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: 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: 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: 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: 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: 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: 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

> > > > 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: 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: 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: 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

  1   2   >