On Wed, 4 Oct 2000, Richard B. Johnson wrote:
> On Wed, 4 Oct 2000, Michael van den broek wrote:
>
> >
> >
> > On Wed, 4 Oct 2000, Richard B. Johnson wrote:
> >
> > > On Tue, 3 Oct 2000, Brett Frankenberger wrote:
> > >
> > > > >
> > > > > S/390 folks run 70,000 sessions active within the
On Wed, 4 Oct 2000, Mark Hahn wrote:
> > Linux 2.2.17 only allows 255 processes at any one time. Is this a
> ...
> > Can't fork any more after 255 processes
>
> ulimit -u
>
> getting back OT, current entry-level PCs (duron/600) can easily
> do 7000 fork/wait pairs per second.
Maybe I have a br
On Wed, 4 Oct 2000, Michael van den broek wrote:
>
>
> On Wed, 4 Oct 2000, Richard B. Johnson wrote:
>
> > On Tue, 3 Oct 2000, Brett Frankenberger wrote:
> >
> > > >
> > > > S/390 folks run 70,000 sessions active within the same 60 second period off
> > > > one big box. Not on Linux (yet ;))
> Linux 2.2.17 only allows 255 processes at any one time. Is this a
...
> Can't fork any more after 255 processes
ulimit -u
getting back OT, current entry-level PCs (duron/600) can easily
do 7000 fork/wait pairs per second.
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
On Wed, 4 Oct 2000, Richard B. Johnson wrote:
> On Tue, 3 Oct 2000, Brett Frankenberger wrote:
>
> > >
> > > S/390 folks run 70,000 sessions active within the same 60 second period off
> > > one big box. Not on Linux (yet ;)) but its worth bearing in mind.
> >
>
> Linux 2.2.17 only allows 2
On Tue, 3 Oct 2000, Brett Frankenberger wrote:
> >
> > S/390 folks run 70,000 sessions active within the same 60 second period off
> > one big box. Not on Linux (yet ;)) but its worth bearing in mind.
>
Linux 2.2.17 only allows 255 processes at any one time. Is this a
'feature'. If so, there i
>
> S/390 folks run 70,000 sessions active within the same 60 second period off
> one big box. Not on Linux (yet ;)) but its worth bearing in mind.
Yes, but they don't do it with 7 separate processes (or "address
spaces" to use the 390 terminology). They have a few processes/address
spaces
On Mon, Oct 02, 2000 at 11:47:41AM +0200, David Weinehall wrote:
> > Thus, "Hoping for security" is meaningless.
> > But "Hoping for more security by having more PID's" is quite
> > reasonable. If I am local user on your system then I can break in
> > using a wraparound. If that takes 2147483647
> On Mon, 2 Oct 2000 11:27:16 +0100 (BST),
> Alan Cox <[EMAIL PROTECTED]> wrote:
> >S/390 folks run 70,000 sessions active within the same 60 second period off
> >one big box. Not on Linux (yet ;)) but its worth bearing in mind.
>
> FYI, OS/390 Unix System Services uses a halfword for the maximu
On Mon, 2 Oct 2000 11:27:16 +0100 (BST),
Alan Cox <[EMAIL PROTECTED]> wrote:
>S/390 folks run 70,000 sessions active within the same 60 second period off
>one big box. Not on Linux (yet ;)) but its worth bearing in mind.
FYI, OS/390 Unix System Services uses a halfword for the maximum number
of
> If you read my entire post, rather than just the part that you quoted,
> you'll see that I argue FOR, not against, a larger pid_t, based on just
> these grounds; I know that sooner or later, we'll need those extra
> processes. Well, my 486 won't...
S/390 folks run 70,000 sessions active within
On Mon, Oct 02, 2000 at 04:16:44AM +0200, Andries Brouwer wrote:
> On Sun, Oct 01, 2000 at 07:51:13PM +0200, David Weinehall wrote:
>
> > Hoping for security just by having more
> > PID's is a bit naive.
>
> *1*
> It is strange that people do not really seem to understand
> the case for a 32-bit
* Andries Brouwer ([EMAIL PROTECTED]) wrote:
> So, in the long run we want a large pid_t. What about the short run?
> For today the disadvantages are negligeable, and for people who
> like security there are definite advantages.
Much more the problem is giving people the *impression* of
a
On Sun, Oct 01, 2000 at 07:51:13PM +0200, David Weinehall wrote:
> Hoping for security just by having more
> PID's is a bit naive.
*1*
It is strange that people do not really seem to understand
the case for a 32-bit pid_t.
This case is: "16 bits is not enough".
We all know that 640KB was enough
14 matches
Mail list logo