RE: Fixing -pthreads (Re: ports and -current)

2003-09-25 Thread David Schwartz
David Xu wrote: I definitly agree with Dan, -pthread is too ugly, it really really is nothing to do with compiler and should be removed. Really? What if invoking the threading library required the compiler to compile code differently? Surely it might require that on some platforms,

RE: Fixing -pthreads (Re: ports and -current)

2003-09-23 Thread David Schwartz
On Mon, 22 Sep 2003, David Schwartz wrote: No. There are other environments that don't have -pthread though. So now FreeBSD will support a flag that numerous other platforms support, however it will support it differently from every other platform. On every other platform I know

RE: Fixing -pthreads (Re: ports and -current)

2003-09-22 Thread David Schwartz
On Sun, 21 Sep 2003, Scott Long wrote: Most everyone that writes threaded applications and runs on multiple platforms knows that most thread libraries are called libpthread and are linked to with -lpthread. Once we rename libkse to libpthread, the problem largely goes away. The porter,

RE: The bikeshed T-shirt

2003-09-11 Thread David Schwartz
At 2:11 AM +0200 2003/09/12, Poul-Henning Kamp wrote: Yes, absolutely. Okay, it should be down in a few minutes. If you are serious about wanting to make the image available to others for use on t-shirts, I would encourage you to set up your own CafePress shop, as one of

Re: ntp problems on sparc

2002-12-19 Thread David Schwartz
On Thu, 19 Dec 2002 21:59:54 -0800, Kris Kennaway wrote: Has anyone else run into the following when trying to run ntpd on sparc? Dec 20 05:51:37 panther2 ntpd[416]: bind() fd 5, family 2, port 123, addr 216.136.204.96, in_classd=0 flags=1 fails: Can't assign requested address The port

RE: randomdev entropy gathering is really weak

2000-07-23 Thread David Schwartz
/dev/random should block if the system does not contain as much real entropy as the reader desires. Otherwise, the PRNG implementation will be the weakest link for people who have deliberately selected higher levels of protection from cryptographic attack. I don't want to rehash this

RE: randomdev entropy gathering is really weak

2000-07-23 Thread David Schwartz
5. Yarrow was designed as a better replacement for most any PRNG by a couple of bright cryptographers. Can you do better than that? Nope, I agree. Ignore my previous objections. DS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in

RE: randomdev entropy gathering is really weak

2000-07-22 Thread David Schwartz
From the Yarrow paper: ``Yarrow's outputs are cryptographically derived. Systems that use Yarrow's outputs are no more secure than the generation mechanism used.'' We currently have Yarrow-256(Blowfish); wanna make it Yarrow-1024? I could make it so. M -- Mark Murray It

RE: randomdev entropy gathering is really weak

2000-07-21 Thread David Schwartz
You generate a new PGP keypair and start using it. Your co-worker reboots your machine afterwards and recovers the PRNG state that happens to be stashed on disk. He can then backtrack and potentially recover the exact same random numbers that you used for your key. If that is

RE: randomdev entropy gathering is really weak

2000-07-17 Thread David Schwartz
Predicting the clock's offset from reality and the two way path to the server of choice is impossible, plus if people enable authentication later on the packets will be choke full of high-quality entropy. Please quantify 'impossible'. Impossible as in cannot be done. The offset

RE: xntpd - VERY old folks, how about updating? :-)

2000-01-02 Thread David Schwartz
That sucks severely - NONE of the common units have the PPS output?! Barf. Oh well. Many of them do, but it's still not meant for precision timekeeping and the exact relationship between its PPS pulse edges and UTC's second boundaries may not be precisely specified. It's not a good

RE: -current will enter feature freeze on December 15th!

1999-11-22 Thread David Schwartz
To that end, we'll be declaring a feature freeze on the 15th, after which time people should just be working on tying off the worst of the spurting arteries and spending more time thinking about fixing things like gdb than thinking about significant architectural changes. With any luck,

RE: luoqi's aic driver problem

1999-10-19 Thread David Schwartz
Probably a Celeron 333a running at an 83.5Mhz FSB. DS Ilya Naumov wrote in list.freebsd-current: Chaintech 6BTM mainboard with Celeron 416A processor and 128 Mb of memory Please excuse me -- what is a "Celeron 416A"? Regards Oliver Fromme To Unsubscribe: send

RE: {a}sync updates (was Re: make install trick)

1999-10-08 Thread David Schwartz
On Thu, Oct 07, 1999 at 03:15:03PM -0700, David Schwartz wrote: There should be fairly few writes to the root partition, so having An opionion. I use the HP workstation model where my / is 1800M. I have You are not disagreeing with him, David. You are just talking about

RE: {a}sync updates (was Re: make install trick)

1999-10-07 Thread David Schwartz
There should be fairly few writes to the root partition, so having An opionion. I use the HP workstation model where my / is 1800M. I have no use for /var and /usr and find them simply stupid in today's world. (except for ISP's where there is cause for a septerate /var). Lets stick to

RE: make install trick

1999-10-05 Thread David Schwartz
I have soft updates enabled on a fast machine at work. make installworld can fill up slash even though it has 15M free before the install. I think this is a bug in softupdates that it doesn't reclaim space quickly enough or in overflow situations. It's really not a bug, it's just

RE: make install trick

1999-10-05 Thread David Schwartz
In message 000101bf0f78$fbe58b40$[EMAIL PROTECTED] "David Schwartz" writes: : It's really not a bug, it's just a missing feature. There's no requirement : that a filesystem reclaim empty space immediately. You really shouldn't be : using fastupdates on nearly full f

RE: Using float emulator on a system with FPU?

1999-07-12 Thread David Schwartz
Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient CPU doesn't have an FPU? And we're talking about the i386 family here... Embedded systems, anyone? True, but how late a version do you really want to run on them? I've left even my P60's at FreeBSD-2.x

RE: net.inet.tcp.always_keepalive on as default ?

1999-06-05 Thread David Schwartz
David Schwartz wrote: Well, we've heard various opinions and I think we can conclude that: 2. That server applications should have keepalives enabled. Well, I certainly don't agree with that. Many server applications (web servers, mail servers, etcetera) already have data

RE: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread David Schwartz
You know, I was going to buy a pickup truck, but I was afraid my neighbors would figure that if I bought a pickup truck, they should buy one too. And maybe a pickup truck isn't the right vehicle for them -- perhaps they didn't even know how to drive one safely. So I bought an Explorer

RE: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread David Schwartz
Well, we've heard various opinions and I think we can conclude that: 2. That server applications should have keepalives enabled. Well, I certainly don't agree with that. Many server applications (web servers, mail servers, etcetera) already have data timeouts, which makes keepalives

RE: net.inet.tcp.always_keepalive on as default ?

1999-06-01 Thread David Schwartz
Why not just fix the application programs that really want timeouts but don't implement them? DS Mind you, this is only a problem because FreeBSD is to bloddy stable: I logged into a customers server a few days a go, it had been up for over a year, and had accumulated tons

RE: net.inet.tcp.always_keepalive on as default ?

1999-06-01 Thread David Schwartz
Saying that it should be an application function is bogus in my book, since the problem is valid for all TCP users, and there are clearly not any reason to duplicate the code in telnetd, ftpd, talkd, c c. But the problem is that every application uses TCP a little bit differently,

RE: net.inet.tcp.always_keepalive on as default ?

1999-06-01 Thread David Schwartz
I think he was suggesting that the apps close the connection if they receive no data from some amount of time. (Isn't this common sense?) DS On Tue, Jun 01, 1999 at 01:30:31PM -0700, Julian Elischer wrote: maybe we should fix our SERVER apps.. e.g. telnetd, sshd, etc. to

RE: net.inet.tcp.always_keepalive on as default ?

1999-06-01 Thread David Schwartz
with the default TCP timeout semantics and doesn't enforce something else is broken. DS On Tue, Jun 01, 1999 at 01:59:48PM -0700, David Schwartz wrote: I think he was suggesting that the apps close the connection if they receive no data from some amount of time. (Isn't this common

RE: More compiler option comparisons

1999-05-25 Thread David Schwartz
With egcs, the '-O' flag doesn't specify the optimization level like it does in GCC. It specifies the desired stability of the generated code. Lower numbers (0,1,2) request higher stability. ;) DS Dan Nelson wrote: -O4 doesn't exist in egcs (or it didn't a month or so ago).

RE: cvs commit: src/sys/pci pcisupport.c

1999-05-12 Thread David Schwartz
I have to comment on this, it's too outrageous. Several times in the past, folks have written in and asked, if they wrote some particular piece of software, would it get committed. They said that it was a large undertaking, and that they wouldn't undertake it, unless there was general

RE: cvs commit: src/sys/pci pcisupport.c

1999-05-12 Thread David Schwartz
Because if it's a day of coding, you should just do it. If it's a 3 month project, you don't waste such time, and you should communicate it. The time factor is judged by folks who code for a living, and maybe it's a little high, but not too bad. I haven't seen this rule misapplied, but

RE: Anybody actually using gigabit ethernet?

1999-05-11 Thread David Schwartz
IMO that's a good thing, because for some reason, the RFC 1323 extensions break a lot of older terminal servers. One could argue that it's more accurate to state that the terminal servers break RFC1323, but alas the effect is the same. DS To Unsubscribe: send mail to

RE: Incorrect memory sizes reported

1999-05-11 Thread David Schwartz
This is normal. It's using a lot of virtual memory. Fortunately, virtual memory is cheap. DS I'm not sure if this is related to the bug I found in 3.1, regarding mmaping devices, then forking, but with my -current NFS server: PID USERNAME PRI NICE SIZERES STATE