On 6 Sep 2000, Linus Torvalds wrote:
In article [EMAIL PROTECTED],
Jeff V. Merkey [EMAIL PROTECTED] wrote:
Linus Torvalds wrote:
Apparently, if you follow the arguments, not having a kernel debugger
leads to various maladies:
- you crash when something goes wrong, and you fsck and it
On Wed, 6 Sep 2000, David S. Miller wrote:
Date: Wed, 6 Sep 2000 17:46:02 -0700 (PDT)
From: [EMAIL PROTECTED]
I guarantee you that IT managers and CTOs do not share your
enthusiasm for slow, correct coding when faced with their business
being down, their revenue stream
On Wed, 6 Sep 2000, Gregory Maxwell wrote:
Finally, who says that acceptance by 'IT managers and CTOs' is actually a
measure of 'quality' that anyone here finds interesting or acceptable? The
very fact that many 'IT managers and CTOs' find NT acceptable speaks
volumes to counter the
On Wed, 6 Sep 2000, Gregory Maxwell wrote:
On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote:
If you'd read what I wrote in it's entirety, you'd know that I'm very well
aware of this perspective.
I read it. I just didn't agree with the level of importance I felt you
were assigning to corporate
On Thu, 7 Sep 2000, Alexander Viro wrote:
On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote:
scale in the end. We'll either see forking, see another OS like FreeBSD
fill the void, or (worst case) Solaris.
Somehow I doubt that arguments from marketshare/field circus/etc. peppered
with threats
On Thu, 7 Sep 2000 [EMAIL PROTECTED] wrote:
Hello!
I believe that the DoS is that the path through the kernel turns out to be
long and that a lot of these packets will bring a machine to its knees.
It is not longer than path for any other kind of packet.
In the reported case it is much
On Wed, 13 Sep 2000, Daniel Quinlan wrote:
"Fixes" - followed by one or more bug numbers (tracked by tytso
for now). For example, "T0001" might be tytso bug
number 0001.
bugzilla. or something else automated to track bugs and assign numbers.
-
To
how about registering the full path (or inode number of the executable?),
the owner, and an optional high water mark of memory consumption, over
which the process is considered to be leaking memory and gets added to the
algorithm of processes to kill? this is because while normally i want to
On Mon, 9 Oct 2000, Byron Stanoszek wrote:
it also might be good to have options to kill anything connected to a pty
first, and to not kill anything attatched to the console. obviously these
leave ways for admins to shoot themselves in the foot, but they could be
useful.
I _had_
I've had to support an app running as a back-end to a webserver that would
malloc() different amounts of memory depending on user input, up to
multiple gigabytes of memory which vastly exceeded the 512k the machine
had as main memory. The app was a program that would scan genetic
sequence
if you aren't comfortable with dropping a lot of the 2.2.18preX stuff onto
a production box, there is also the 2.2.18pre2aa2 kernel that andrea made
which has the VM stuff. check out andrea/proposed/v2.2/2.2.18pre2 or
andrea/kernels/v2.2/2.2.18pre2aa2
unless you've made substantial updates to
On Thu, 5 Oct 2000, Neil Brown wrote:
2/ Arrange your filesystem so that you write new data to an otherwise
unused stripe a whole stripe at a time, and store some sort of
chechksum in the stripe so that corruption can be detected. This
implies a log structured filesystem (though
On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote:
This user also wants a
smooth GUI, a mouse pointer that doesn't flinch under load,
Try andrea archangeli's VM patches. When I use those patches X gets much
smoother and xmms (with nice -5) never skips. 2.2 VM sucks, film at 11.
and a
I had tons of problems with K6III/450s in ASUS P5A motherboards with
various kinds of 128MB SIMMs. There were multiple different symptoms,
including just sig11s on compiles, corrupted input (leading to syntax
error) in compiles, and corrupted input in the buffer cache (same crash
over and over,
bkz, any chance of a backport of this backport to 2.2.17?
On Fri, 27 Oct 2000, Andre Hedrick wrote:
Hi Bart,
The point is that I have stopped with the backport because of 2.4.0 push,
and I was waiting on you to pick it up again.
if you look at the kstat structure under solaris, there's a lot of info
there that'd be good to be able to pull out of the linux kernel. that
would slow down the kernel a little, lead to some 'bloat' that linus
abhors and such, but its good to have that information for monitoring and
debugging
On 6 Sep 2000, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> Jeff V. Merkey <[EMAIL PROTECTED]> wrote:
> >Linus Torvalds wrote:
> >
> >> Apparently, if you follow the arguments, not having a kernel debugger
> >> leads to various maladies:
> >> - you crash when something goes wrong,
On Wed, 6 Sep 2000, David S. Miller wrote:
>Date: Wed, 6 Sep 2000 17:46:02 -0700 (PDT)
>From: <[EMAIL PROTECTED]>
>
>I guarantee you that IT managers and CTOs do not share your
>enthusiasm for slow, correct coding when faced with their business
>being down, their revenue
On Wed, 6 Sep 2000, Gregory Maxwell wrote:
> Finally, who says that acceptance by 'IT managers and CTOs' is actually a
> measure of 'quality' that anyone here finds interesting or acceptable? The
> very fact that many 'IT managers and CTOs' find NT acceptable speaks
> volumes to counter the
On Wed, 6 Sep 2000, Gregory Maxwell wrote:
> On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote:
> > If you'd read what I wrote in it's entirety, you'd know that I'm very well
> > aware of this perspective.
>
> I read it. I just didn't agree with the level of importance I felt you
> were assigning to
On Thu, 7 Sep 2000, Alexander Viro wrote:
> On Wed, 6 Sep 2000 [EMAIL PROTECTED] wrote:
> > scale in the end. We'll either see forking, see another OS like FreeBSD
> > fill the void, or (worst case) Solaris.
>
> Somehow I doubt that arguments from marketshare/field circus/etc. peppered
> with
On Thu, 7 Sep 2000 [EMAIL PROTECTED] wrote:
> Hello!
> > - Could there be some kind of handling for such packets (meaning TCP packets
> > reaching at an unused port with ACK bit set - with no previous SYN etc packet)
> > to avoid such DoS attacks? Is the same happening to newer kernels? If
On Thu, 7 Sep 2000 [EMAIL PROTECTED] wrote:
> Hello!
> > I believe that the DoS is that the path through the kernel turns out to be
> > long and that a lot of these packets will bring a machine to its knees.
>
> It is not longer than path for any other kind of packet.
> In the reported case it
Connecting to 204.201.36.164...
elijah.nodomainname.net FTP server (Version wu-2.5.0(1) Wed Aug 25
14:13:56 EDT
has a /pub/linux/kernel/people/alan that is out of date (latest is
2.2.15pre)
and,
Connecting to 198.186.203.38...
On Mon, 11 Sep 2000, Andrea Arcangeli wrote:
> On Fri, 8 Sep 2000, Matthew Hawkins wrote:
> >Something between bigmem and his big VM changes makes reiserfs
> >uncompilable. [..]
>
> It's due LFS. Chris should have a reiserfs patch that compiles on top of
> 2.2.18pre2aa2, right? (if not Chris, I
On Wed, 13 Sep 2000, Daniel Quinlan wrote:
> "Fixes" - followed by one or more bug numbers (tracked by tytso
> for now). For example, "T0001" might be tytso bug
> number 0001.
bugzilla. or something else automated to track bugs and assign numbers.
-
To
there's already the Linux Scalability Project's wake_one() patch for 2.2.9
(which applies fine to 2.2.18preX):
http://www.citi.umich.edu/projects/linux-scalability/patches/p_accept-2.2.9.diff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
I had tons of problems with K6III/450s in ASUS P5A motherboards with
various kinds of 128MB SIMMs. There were multiple different symptoms,
including just sig11s on compiles, corrupted input (leading to syntax
error) in compiles, and corrupted input in the buffer cache (same crash
over and over,
how about registering the full path (or inode number of the executable?),
the owner, and an optional high water mark of memory consumption, over
which the process is considered to be leaking memory and gets added to the
algorithm of processes to kill? this is because while normally i want to
On Mon, 9 Oct 2000, Byron Stanoszek wrote:
> > it also might be good to have options to kill anything connected to a pty
> > first, and to not kill anything attatched to the console. obviously these
> > leave ways for admins to shoot themselves in the foot, but they could be
> > useful.
>
> I
I've had to support an app running as a back-end to a webserver that would
malloc() different amounts of memory depending on user input, up to
multiple gigabytes of memory which vastly exceeded the 512k the machine
had as main memory. The app was a program that would scan genetic
sequence
if you aren't comfortable with dropping a lot of the 2.2.18preX stuff onto
a production box, there is also the 2.2.18pre2aa2 kernel that andrea made
which has the VM stuff. check out andrea/proposed/v2.2/2.2.18pre2 or
andrea/kernels/v2.2/2.2.18pre2aa2
unless you've made substantial updates to
On Thu, 5 Oct 2000, Neil Brown wrote:
> 2/ Arrange your filesystem so that you write new data to an otherwise
>unused stripe a whole stripe at a time, and store some sort of
>chechksum in the stripe so that corruption can be detected. This
>implies a log structured filesystem
On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote:
> This user also wants a
> smooth GUI, a mouse pointer that doesn't flinch under load,
Try andrea archangeli's VM patches. When I use those patches X gets much
smoother and xmms (with nice -5) never skips. 2.2 VM sucks, film at 11.
> and a
bkz, any chance of a backport of this backport to 2.2.17?
On Fri, 27 Oct 2000, Andre Hedrick wrote:
> Hi Bart,
>
> The point is that I have stopped with the backport because of 2.4.0 push,
> and I was waiting on you to pick it up again.
>
>
if you look at the kstat structure under solaris, there's a lot of info
there that'd be good to be able to pull out of the linux kernel. that
would slow down the kernel a little, lead to some 'bloat' that linus
abhors and such, but its good to have that information for monitoring and
debugging
are using this, or plan to do so?
Debian's 2.13-13 version is actually 2.13.1-rc2 (looking at
git://git.debian.org/~lamont/util-linux.git) minus the pofile
changes (plus some debian-local stuff), and has been in unstable
since 5 December 2007. 2.13~rc2-3 was the first non-experimental
upload (28
resting. Thanks. Which distros are using this, or plan to do so?
Debian's 2.13-13 version is actually 2.13.1-rc2 (looking at
git://git.debian.org/~lamont/util-linux.git) minus the pofile
changes (plus some debian-local stuff), and has been in unstable
since 5 December 2007. 2.13~rc2-3 was th
38 matches
Mail list logo
