:Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
:> -pipe makes a significant difference since without it every source
:> file being compiled creates several files in /tmp.
:
:Hasn't O'Brien recently said that in fact "-pipe" is already the
:default for our cc, so explicitly specifying the op
On Mon, 24 Apr 2000, Ben Smithurst wrote:
> why allow csh in the Makefile when the setting of DEFSHELL it results in
> will not compile? Have I missed something?
It's there to allow you attempt to shoot yourself in the foot more safely.
Too much shooting, still?
> --
> Ben Smithurst / [EMAIL
On Mon, Apr 24, 2000 at 05:17:10AM +0300, A G F Keahan wrote:
> I am currently porting a multithreaded TCP server from NT (yech!) to
> UNIX using pthreads. The server has a fairly straightforward design --
> it opens a thread for each connection, and each thread spends most of
> its life blocked
Brian Fundakowski Feldman wrote:
> +.if ${MAKE_SHELL} == "csh"
> +CFLAGS+= -DDEFSHELL=0
...
> +#if DEFSHELL == 1
> (void) execv("/bin/sh", args);
> +#elif DEFSHELL == 2
> + (void) execv("/bin/ksh", args);
> +#else
> +#error "DEFSHELL must be 1 or 2."
> +#endif
why allow csh in th
On Sun, 23 Apr 2000, Brian Fundakowski Feldman wrote:
> On Sun, 23 Apr 2000, Chuck Robey wrote:
>
> > in general, it's a good idea, but the problem, is, it gives a lot more
> > freedom without any real gain. It only allows one to write Makefiles that
> > use your private choice of shell, and yo
On Sun, 23 Apr 2000, Chuck Robey wrote:
> in general, it's a good idea, but the problem, is, it gives a lot more
> freedom without any real gain. It only allows one to write Makefiles that
> use your private choice of shell, and you can do anything you want, I
> think, as it is now.
That's not
I have been using it as well (with pdksh) for quite some time. I haven't
compared speed, but it certainly hasn't broken anything.
Robert Muir
[EMAIL PROTECTED]
On Sun, 23 Apr 2000, Brian Fundakowski Feldman wrote:
> Some weeks ago, I made a small modification to make(1) so that it could
> be b
I am currently porting a multithreaded TCP server from NT (yech!) to
UNIX using pthreads. The server has a fairly straightforward design --
it opens a thread for each connection, and each thread spends most of
its life blocked in a call to read() from a socket. As soon as it
receives enough of
On Sun, 23 Apr 2000, Brian Fundakowski Feldman wrote:
> Some weeks ago, I made a small modification to make(1) so that it could
> be built to use a different shell for its work. It already seemed to
> have the idea at least partially thought out and in the code, so it was
> a naturally easy thin
On Sunday, 23 April 2000 at 18:25:28 +0200, Mark Huizer wrote:
> On Sun, Apr 23, 2000 at 11:42:18AM +0930, Greg Lehey wrote:
>> On Thursday, 13 April 2000 at 13:20:50 +0200, Mark Huizer wrote:
>>> Hi
>>>
>>> I'm trying to debug a kernel that is not crashing but hanging, with all
>>> processes in '
Robert Watson writes:
> > You should go promiscuous to multicast. If the card doesn't support
> > that, you should go fully promiscuous and drop unicasts that aren't
> > to you. (Make sure you don't block packets that bpf is going to
> > want to see).
>
> Also, if you want bridging support, you
Some weeks ago, I made a small modification to make(1) so that it could
be built to use a different shell for its work. It already seemed to
have the idea at least partially thought out and in the code, so it was
a naturally easy thing to finish implementing. The code will remain
exactly the sam
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> -pipe makes a significant difference since without it every source
> file being compiled creates several files in /tmp.
Hasn't O'Brien recently said that in fact "-pipe" is already the
default for our cc, so explicitly specifying the option doe
:>
:> I don't know what your setup is, Kent, but when I do a buildworld
:> my system is 95% cpu bound, with virtual no idle time at all. It's
:> all going to the buildworld. On both 3.x and 4.x.
:
:It is on 4.x but it wasn't on 3.4. At least, seti was taking time that
:it shouldn't
Matthew Dillon wrote:
>
> :The bugs were fixed in 4.0? What I saw was far too much cpu going to
> :setiathome on 3.4. Seti hardly ran on 4.0. I don't have quantities
> :because I have only noticed the really large increase in cpu time
> :required to build 4.0. The wall clock time on a buildworld
> > I once put in an extra digit in the serial number.
> > This made a secondary use a serial number, which was larger than mine, and
> > could probably be the modulus 2^32.
> > I had to call the hostmaster there (A "3.rd secondary" hosted at our
> > uplink) to get the zonefile removed, so the rig
* Leif Neland ([EMAIL PROTECTED]) [000423 13:17]:
> I once put in an extra digit in the serial number.
> This made a secondary use a serial number, which was larger than mine, and
> could probably be the modulus 2^32.
> I had to call the hostmaster there (A "3.rd secondary" hosted at our
> uplink
:You can not be sure your secondary dns servers are picking up your
:zonefile, when you update the primary.
:
You can 'reset' (roll-over) the serial number, but when you do
so you have to realize that the secondaries may continue to cache
the 'old' version of the zone file all the w
You can not be sure your secondary dns servers are picking up your
zonefile, when you update the primary.
On Sun, 23 Apr 2000, Evren Yurtesen wrote:
> well ours is still working fine !
> thats why I asked this question, we did not realize that it went over 32
> bit boundary
> how can I underst
:The bugs were fixed in 4.0? What I saw was far too much cpu going to
:setiathome on 3.4. Seti hardly ran on 4.0. I don't have quantities
:because I have only noticed the really large increase in cpu time
:required to build 4.0. The wall clock time on a buildworld hardly
:changed (55-60 minutes)
On Fri, 21 Apr 2000, Bill Fenner wrote:
> >What should I do when I see ALLMULTI?
>
> You should go promiscuous to multicast. If the card doesn't support
> that, you should go fully promiscuous and drop unicasts that aren't
> to you. (Make sure you don't block packets that bpf is going to
> wan
On Sun, 23 Apr 2000, Evren Yurtesen wrote:
> Hello,
>
> is the bind have 32 bit unsigned integer variable for the serial
> number part of the dns records?
> if yes, it means that we cant have a number bigger than
> 4294967296 right?
Somewhere I read something like: "The format MMDDnn" is
well ours is still working fine !
thats why I asked this question, we did not realize that it went over 32
bit boundary
how can I understand if there is a problem or not?
Evren
On Sun, 23 Apr 2000, Dave Dunaway wrote:
>
> Put a number bigger than 2^32 and it will overflows.
>
> > is the bind h
On Sun, Apr 23, 2000 at 11:42:18AM +0930, Greg Lehey wrote:
> On Thursday, 13 April 2000 at 13:20:50 +0200, Mark Huizer wrote:
> > Hi
> >
> > I'm trying to debug a kernel that is not crashing but hanging, with all
> > processes in 'inode' wchan. So I did a 'call panic()', and now I have
> > the cr
Hello,
is the bind have 32 bit unsigned integer variable for the serial
number part of the dns records?
if yes, it means that we cant have a number bigger than
4294967296 right? what happens if we have a bigger number?
then bind takes it like modulus 2^32? or it is forbidden to
have a bigger numb
Matthew Dillon wrote:
>
> :You are right but that is because I haven't started keeping record on
> :4.0-Stable and we were comparing apples and oranges. A buildworld of
> :3.4-Stable required around 2000u seconds using gcc-2.8.2 on my system.
> :Setiathome, which is running at a nice of 19, sti
26 matches
Mail list logo
