9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] Re: patch/list sorry/nbroken-8
@ 2006-03-30 12:15 Fco. J. Ballesteros
  0 siblings, 0 replies; 8+ messages in thread
From: Fco. J. Ballesteros @ 2006-03-30 12:15 UTC (permalink / raw)
  To: 9fans

:  > Note also that keeping a customized version of the kernel source locally is
:  > completely unacceptable.
:

Ok . I'll rm -r /sys/src/planb here in that case :-)
I'm sorry.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] Re: patch/list sorry/nbroken-8
  2006-03-29 23:37     ` Russ Cox
  2006-03-30  1:56       ` geoff
@ 2006-03-30 10:52       ` Richard Miller
  1 sibling, 0 replies; 8+ messages in thread
From: Richard Miller @ 2006-03-30 10:52 UTC (permalink / raw)
  To: 9fans

> Note also that keeping a customized version of the kernel source locally is
> completely unacceptable.

Where's the fun in using an open source OS if you don't customise your own
version?



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] Re: patch/list sorry/nbroken-8
  2006-03-29 23:37     ` Russ Cox
@ 2006-03-30  1:56       ` geoff
  2006-03-30 10:52       ` Richard Miller
  1 sibling, 0 replies; 8+ messages in thread
From: geoff @ 2006-03-30  1:56 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 172 bytes --]

Actually, I pull -s the new file,

	idiff `{yesterday file} file >NEW

Once I'm convinced that NEW is a correct merger,

	cp NEW file

It's a tiny amount of work.

[-- Attachment #2: Type: message/rfc822, Size: 3085 bytes --]

From: "Russ Cox" <rsc@swtch.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: patch/list sorry/nbroken-8
Date: Wed, 29 Mar 2006 18:37:39 -0500
Message-ID: <01e4f0edc05e0e36f9393457b6df9325@swtch.com>

> Note also that keeping a customized version of the kernel source locally is
> completely unacceptable.

You keep saying that, but that doesn't make it true.

It's actually very common for people to keep customized
versions of source in /sys/src.  When you pull, if one of
those files is new then you have to diff it and make the
changes by hand, then run pull -c to tell replica that
you've taken care of that.  It's not hard.

Russ

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] Re: patch/list sorry/nbroken-8
  2006-03-29 23:01   ` uriel
  2006-03-29 23:28     ` Skip Tavakkolian
@ 2006-03-29 23:37     ` Russ Cox
  2006-03-30  1:56       ` geoff
  2006-03-30 10:52       ` Richard Miller
  1 sibling, 2 replies; 8+ messages in thread
From: Russ Cox @ 2006-03-29 23:37 UTC (permalink / raw)
  To: 9fans

> Note also that keeping a customized version of the kernel source locally is
> completely unacceptable.

You keep saying that, but that doesn't make it true.

It's actually very common for people to keep customized
versions of source in /sys/src.  When you pull, if one of
those files is new then you have to diff it and make the
changes by hand, then run pull -c to tell replica that
you've taken care of that.  It's not hard.

Russ



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] Re: patch/list sorry/nbroken-8
  2006-03-29 23:01   ` uriel
@ 2006-03-29 23:28     ` Skip Tavakkolian
  2006-03-29 23:37     ` Russ Cox
  1 sibling, 0 replies; 8+ messages in thread
From: Skip Tavakkolian @ 2006-03-29 23:28 UTC (permalink / raw)
  To: 9fans

> Note also that keeping a customized version of the kernel source locally is
> completely unacceptable.

where are these hard-and-fast rules written? by whome?



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] Re: patch/list sorry/nbroken-8
  2006-03-29 22:47 ` uriel
  2006-03-29 22:57   ` Steve Simon
@ 2006-03-29 23:01   ` uriel
  2006-03-29 23:28     ` Skip Tavakkolian
  2006-03-29 23:37     ` Russ Cox
  1 sibling, 2 replies; 8+ messages in thread
From: uriel @ 2006-03-29 23:01 UTC (permalink / raw)
  To: 9fans

>> d-rwxrwxr-x M 430 uriel sys 0 Mar 29 17:38 sorry/nbroken-8
>> from uriel@cat-v.org
>> 	/sys/src/9/port/proc.c
>> 	Upper NBROKEN to 8 to avoid lossing broken procs in long-running cpu servers.
>>
>> Wed Mar 29 17:37:57 EST 2006 rsc
>>     This is an arbitrary choice.  Why not 16?
>>     If you want to make it different in your own systems go ahead,

Note also that keeping a customized version of the kernel source locally is
completely unacceptable.

uriel



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9fans] Re: patch/list sorry/nbroken-8
  2006-03-29 22:47 ` uriel
@ 2006-03-29 22:57   ` Steve Simon
  2006-03-29 23:01   ` uriel
  1 sibling, 0 replies; 8+ messages in thread
From: Steve Simon @ 2006-03-29 22:57 UTC (permalink / raw)
  To: 9fans

> Note that others have also reported broken procs 'vanishing', probably
> because they didn't know there was a limit and that the limit was so
> low.

That is a missquote, I said I noticed broken
processes being tidied up.

I am glad of it, I had httpd commiting hari-kari a
dozen times a day a week or two ago and was very pleased
the broken procs didn't build up.

-Steve


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [9fans] Re: patch/list sorry/nbroken-8
       [not found] <e644f5197ca0a9d59548f0fcf0c49f52@plan9.bell-labs.com>
@ 2006-03-29 22:47 ` uriel
  2006-03-29 22:57   ` Steve Simon
  2006-03-29 23:01   ` uriel
  0 siblings, 2 replies; 8+ messages in thread
From: uriel @ 2006-03-29 22:47 UTC (permalink / raw)
  To: 9fans

> d-rwxrwxr-x M 430 uriel sys 0 Mar 29 17:38 sorry/nbroken-8
> from uriel@cat-v.org
> 	/sys/src/9/port/proc.c
> 	Upper NBROKEN to 8 to avoid lossing broken procs in long-running cpu servers.
>
> Wed Mar 29 17:37:57 EST 2006 rsc
>     This is an arbitrary choice.  Why not 16?
>     If you want to make it different in your own systems go ahead,
>     but I don't see the point here.
>
>     The default is fine as it is.
IMHO the default is way too low (and undocumented as far as I can
tell.) 8 is also arbitrary, but seems like a much more reasonable
value in most cases, going over 4 broken processes is not hard if you
have bad luck and a long running box, going over 8 broken processes is
considerably harder, like all magic numbers, all matter of judgement
and experimentation.

Note that others have also reported broken procs 'vanishing', probably
because they didn't know there was a limit and that the limit was so
low.

uriel



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2006-03-30 12:15 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-03-30 12:15 [9fans] Re: patch/list sorry/nbroken-8 Fco. J. Ballesteros
     [not found] <e644f5197ca0a9d59548f0fcf0c49f52@plan9.bell-labs.com>
2006-03-29 22:47 ` uriel
2006-03-29 22:57   ` Steve Simon
2006-03-29 23:01   ` uriel
2006-03-29 23:28     ` Skip Tavakkolian
2006-03-29 23:37     ` Russ Cox
2006-03-30  1:56       ` geoff
2006-03-30 10:52       ` Richard Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).