On 2005-04-12, at 04:17, Larry McVoy wrote whatever...
Excuse me, but: who gives a damn shit?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
On 2005-04-11, at 04:26, Miles Bader wrote:
Marcin Dalecki <[EMAIL PROTECTED]> writes:
Better don't waste your time with looking at Arch. Stick with patches
you maintain by hand combined with some scripts containing a list of
apply commands and you should be still more productive then
On 2005-04-09, at 17:42, Paul Jackson wrote:
Marcin wrote:
But what will impress you are either the price tag the
DB comes with or
the hardware it runs on :-)
The payroll for the staffing to care and feed for these
babies is often impressive as well.
Please don't forget the bill from the electric p
On 2005-04-09, at 03:09, Chris Wedgwood wrote:
On Sat, Apr 09, 2005 at 03:00:44AM +0200, Marcin Dalecki wrote:
Yes it sucks less for this purpose. See subversion as reference.
Whatever solution people come up with, ideally it should be tolerant
to minor amounts of corruption (so I can recover the
On 2005-04-08, at 20:28, Jon Smirl wrote:
On Apr 8, 2005 2:14 PM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
How do you replicate your database incrementally? I've given you
enough
clues to do it for "git" in probably five lines of perl.
Efficient database replication is achieved by copying t
On 2005-04-08, at 20:14, Linus Torvalds wrote:
On Fri, 8 Apr 2005, Matthias-Christian Ott wrote:
Ok, but if you want to search for information in such big text files
it
slow, because you do linear search
No I don't. I don't search for _anything_. I have my own
content-addressable filesystem, and
On 2005-04-08, at 19:14, Linus Torvalds wrote:
You do that with an sql database, and I'll be impressed.
It's possible. But what will impress you are either the price tag the
DB comes with or
the hardware it runs on :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
On 2005-04-06, at 23:13, [EMAIL PROTECTED] wrote:
Linus Torvalds wrote:
PS. Don't bother telling me about subversion. If you must, start
reading
up on "monotone". That seems to be the most viable alternative, but
don't
pester the developers so much that they don't get any work done. They
are
alr
On 2005-04-07, at 09:44, Jan Hudec wrote:
I have looked at most systems currently available. I would suggest
following for closer look on:
1) GNU Arch/Bazaar. They use the same archive format, simple, have the
concepts right. It may need some scripts or add ons. When Bazaar-NG
is ready, it wi
On 2005-04-08, at 18:15, Matthias-Christian Ott wrote:
Linus Torvalds wrote:
SQL Databases like SQLite aren't slow.
But maybe a Berkeley Database v.4 is a better solution.
Yes it sucks less for this purpose. See subversion as reference.
-
To unsubscribe from this list: send the line "unsubscribe l
On 2005-03-30, at 01:39, Benjamin Herrenschmidt wrote:
On Tue, 2005-03-29 at 17:25 -0600, Chris Friesen wrote:
Lee Revell wrote:
This is the exact line of reasoning that led to Winmodems.
My main issue with winmodems is not so much the software offload, but
rather that the vendors don't release ful
On 2005-03-30, at 00:13, Lee Revell wrote:
On Tue, 2005-03-29 at 11:22 +0200, Marcin Dalecki wrote:
No. You didn't get it. I'm taking the view that mixing sound is simply
a task you would typically love to make a DSP firmware do.
However providing a DSP for sound processing at 44kHZ o
On 2005-03-29, at 12:22, Takashi Iwai wrote:
ALSA provides the "driver" feature in user-space because it's more
flexible, more efficient and safer than doing in kernel. It's
transparent from apps perspective. It really doesn't matter whether
it's in kernel or user space.
Yes because it's that won
On 2005-03-29, at 10:18, Benjamin Herrenschmidt wrote:
Well, we are claiming _and_ obviously proposing a solution ;)
I beg to differ.
1. Where do you have true "real-time" under linux? Kernel or user
space?
That's bullshit.
Wait a moment...
you don't need "true" real time for the mixing/volume
pro
On 2005-03-29, at 05:36, Lee Revell wrote:
On Mon, 2005-03-28 at 09:42 +1000, Benjamin Herrenschmidt wrote:
It seems that Apple's driver has an in-kernel framework for doing
volume
control, mixing, and other horrors right in the kernel, in temporary
buffers, just before they get DMA'ed (gack !)
I
On 2005-03-27, at 04:00, Horst von Brand wrote:
Needless to say that there are enough architectures out there, which
don't even have something like an explicit call as separate assembler
instruction...
The mechanism exists somehow.
Most RISC architectures are claiming a huge register set advantage
On 2005-03-27, at 00:21, linux-os wrote:
Always, always, a call will be more expensive than a branch
on condition. It's impossible to be otherwise. A call requires
that the return address be written to memory (the stack),
using register indirection (the stack-pointer).
Needless to say that there ar
On 2005-03-26, at 16:19, Arjan van de Ven wrote:
`
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC
BadCRC is 99% sure a cabling issue; either a bad/overheated cable or a
cable used at too high a speed for the cable.
No. It is more lik
On 2005-02-14, at 19:56, Larry McVoy wrote:
All we are trying to do is
1. Provide the open source community with a useful tool.
2. Prevent that from turning into the open source community
creating a clone of our tool.
Now that's pathetic!
You recognize that point 2. is precisely t
On 2005-02-14, at 19:17, Matthew Jacob wrote:
I mean- you're certainly free to impose whatever license you want, and
others are free to be happy or unhappy with that. I'm just trying to
figure out what you're actually trying to accomplish here.
He is simply plain dishonest about his intentions. And
On 2005-02-14, at 18:49, Larry McVoy wrote:
r it we'd be happy to negotiate a standard
click-wrap style license as part of the deal. Everyone would like that
much better it seems. Are you volunteering to pay?
I'm not since I'm not using and I don't intend to use BK.
Oh BTW. the main reason for me
On 2005-02-14, at 17:00, Larry McVoy wrote:
On Mon, Feb 14, 2005 at 10:03:45AM -0500, Steven Rostedt wrote:
Can you see Ford Motors telling
someone that you can't go work for GM if you drive a Ford?
You paid for the Ford. Suppose Ford offered to give you the car but
said if you take it then you ca
On 2005-02-14, at 16:40, Larry McVoy wrote:
So how would you suggest that we resolve it? The protection we need is
that people don't get to
- use BK
- stop using BK so they can go work on another system
- start using BK again
- stop using BK so they can go work on another system
On 2005-01-19, at 04:35, H. Peter Anvin wrote:
Matt Mackall wrote:
I would argue that "name of gcc has changed" is possibly a condition
that does more harm than good. It is just as frequently used to have
wrappers, like distcc, as it is to have different versions.
Disagree. I switch compilers all
I ahve a PC box at hand, which ist containing 8 PCI slots.
Four of them are sitting behind a PCI bridge.
The error in the new kernel series is that during the
PCI bus setup if a card is sitting behind the bridge, it
will be miracelously detected TWICE. Once in front of the
bridge and once behind t
William Park wrote:
>
> On Mon, Jun 25, 2001 at 08:51:28PM +0200, Martin Dalecki wrote:
> > Just a note...
> >
> > This card get's detected twofold by the plain 2.4.5 kernel.
> > It get's listed twice under both lspci and during the kernel boot
> >
Just a note...
This card get's detected twofold by the plain 2.4.5 kernel.
It get's listed twice under both lspci and during the kernel boot
sequence on a HP LHr3 system.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More m
Mike Harrold wrote:
> So what? Crusoe isn't designed for use in supercomputers. It's designed
> for use in laptops where the user is running an email reader, a web
> browser, a word processor, and where the user couldn't give a cr*p about
> performance as long as it isn't noticeable (20% *isn't* f
Rob Landley wrote:
> The same arguments were made 30 years ago about writing the OS in a high
> level language like C rather than in raw assembly. And back in the days of
> the sub-1-mhz CPU, that really meant something.
And then those days we are still writing lot's of ASM in kernels...
> I d
Joel Becker wrote:
>
> On Wed, May 30, 2001 at 05:24:37PM -0700, Jonathan Lundell wrote:
> > FWIW (perhaps not much in this context), the POSIX way is sysconf(_SC_CLK_TCK)
> >
> > POSIX sysconf is pretty useful for this kind of thing (not just HZ, either).
>
> Well, how many hundred thin
> Standard is right.
> Believe me as someone who are living in Belarus ;-)
OK. I trust you.
>
> Official country name: Belarus
> Language/Nationality: Belarusian
>
> Standard has taken things right as we pronounce them.
>
> Please apply the patc
Linus Torvalds wrote:
>
> On Tue, 22 May 2001, Jeff Garzik wrote:
> >
> > IMHO it would be nice to (for 2.4) create wrappers for accessing the
> > block arrays, so that we can more easily dispose of the arrays when 2.5
> > rolls around...
>
> No.
>
> We do not create wrappers "so that we can ea
w/drivers/char/raw.c Mon Apr 30 22:57:20 2001
@@ -124,22 +124,25 @@
return err;
}
-
- /*
-* Don't interfere with mounted devices: we cannot safely set
- * the blocksize on a device which is already mounted.
+ /*
+* 29.04.2001 Martin Dalecki:
+
And if we are at the topic... Those are the places where blk_size[]
get's
abused, since it's in fact a property of a FS in fact and not the
property of
a particular device... blksect_size is the array describing the physical
access limits of a device and blk_size get's usually checked against it.
[EMAIL PROTECTED] wrote:
>
> Martin Dalecki writes:
>
> > Erm... I wasn't talking about the DESIRED state of affairs!
> > I was talking about the CURRENT state of affairs. OK?
>
> Oh, but in 1995 it was quite possible to compile the kernel
> with kdev_t
[EMAIL PROTECTED] wrote:
>
> Martin Dalecki writes:
>
> > I fully agree with you.
>
> Good.
>
> Unfortunately I do not fully agree with you.
>
> > Most of the places where there kernel is passing kdev_t
> > would be entierly satisfied with only the k
[EMAIL PROTECTED] wrote:
>
> > They are entirely different. Too different sets of operations.
>
> Maybe you didnt understand what I meant.
> both bdev and cdev take care of the correspondence
> device number <---> struct with operations.
>
> The operations are different, but all bdev/cdev code
Andrzej Krzysztofowicz wrote:
>
> Hi,
> The following patch cleans up a bit usage of parameters related to
> number of minors per disk in the SCSI subsystem. This is a preliminary
> patch and it seems to not contain any problematic changes. The full version
> of the patch (that allows to succes
Linus Torvalds wrote:
> and then use
>
> fd = open("/dev/fd0/colourspace", O_RDWR);
> This, btw, is Al Viro's wet dream. But I have to agree: using name spaces
> etc is MUCH preferable to ioctl's, makes code more readable and logical,
> and often makes it possible to do things you could
Linus Torvalds wrote:
>
> On Mon, 14 May 2001, Alan Cox wrote:
> >
> > Except that Linus wont hand out major numbers, which means I can't even boot
> > simply off such a device. I bet the vendors in question dont think the sun
> > shines out of linus backside any more.
>
> Actually, it does. It'
> - Political fixes:
> o There were still some penguins left carrying a glass of beer or wine.
> This problem is about 2 years old!
Could You please for the sake of political correctness just replace
the beer with a glass of vodka please... It tastes better anyway!
-
To unsubscrib
Andrea Arcangeli wrote:
>
> On Wed, May 09, 2001 at 11:13:33AM +0200, Martin Dalecki wrote:
> > > (buffered and direct) to work with a 4096 bytes granularity instead of
> >
> > You mean PAGE_SIZE :-).
>
> In my first patch it is really 4096 bytes, but yes I
Andrea Arcangeli wrote:
> (btw, also the current rawio uses a 512byte bh->b_size granularity that is even
> worse than the 1024byte b_size of the blkdev, O_DIRECT is much smarter
> on this side as it uses the softblocksize of the fs that can be as well
> 4k if you created the fs with -b 4096)
Am
Rusty Russell wrote:
>
> In message <[EMAIL PROTECTED]> you write:
> >
> > Jonathan Morton writes:
> > > >- page_count(page) == (1 + !!page->buffers));
> > >
> > > Two inversions in a row?
> >
> > It is the most straightforward way to make a '1' or '0'
> > integer from the NUL
"H. Peter Anvin" wrote:
>
> Hi guys,
>
> I was looking over the iso9660 code, and noticed that it was doing
> endianness conversion via ad hoc *functions*, not even inlines; nor did
> it take any advantage of the fact that iso9660 is bi-endian (has "all"
> data in both bigendian and littleendian
/*
-* Don't interfere with mounted devices: we cannot safely set
- * the blocksize on a device which is already mounted.
+ /*
+* 29.04.2001 Martin Dalecki:
+*
+* The original comment here was saying:
+*
+* "Don&#x
Alexander Viro wrote:
>
> On Sat, 28 Apr 2001, Martin Dalecki wrote:
>
> > I think in the context you are inventig the proposed function,
> > the drivers has allways an inode at hand. And contrary to what Linus
>
> Read the patch. Almost all cases are of the &
Alexander Viro wrote:
>
> On Fri, 27 Apr 2001, Alexander Viro wrote:
>
> > Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
> > either sync_dev() or fsync_dev(). What do you think about pulling that
> > into the same function? Actually, that's what I've done in namespace
>
Linus Torvalds wrote:
> Dump was a stupid program in the first place. Leave it behind.
Not quite Linus - dump/restore are nice tools to create for example
automatic over network installation servers, i.e. efficient system
images
or such. tar/cpio and friends don't deal properly with
a. holes in
[EMAIL PROTECTED] wrote:
>
> From: Martin Dalecki <[EMAIL PROTECTED]>
>
> The attached patch is fixing georgeous "backward compatibility"
> in the mount system command. It is removing two useless defines in
> the kernel headers and fina
Ingo Oeser wrote:
>
> On Thu, Apr 26, 2001 at 10:58:46AM +0200, Martin Dalecki wrote:
> > 1. Help making the module interface cleaner by a tinny margin :-).
>
> You only help changing the API during a stable[1] series. Wait until 2.5
> for this.
>
> API cannot change
Hello!
The following patch is making the get_empty_super() function
just local to the place where it's only use is and where it's only
use should be: fs/super.c
The removal of this symbol from ksyms.c should:
1. Help making the module interface cleaner by a tinny margin :-).
2. shouldn't hurt
The attached patch is fixing georgeous "backward compatibility"
in the mount system command. It is removing two useless defines in
the kernel headers and finally doubles the number of possible
flags for the mount command.
Please apply.
If there are any line count difference warnings when applyin
Tim Jansen wrote:
>
> On Tuesday 24 April 2001 11:40, Martin Dalecki wrote:
> > Tim Jansen wrote:
> > > The Linux Device Registry (devreg) is a kernel patch that adds a device
> > > database in XML format to the /proc filesystem. It collects all
> > OH SHIT!!
Tim Jansen wrote:
>
> The Linux Device Registry (devreg) is a kernel patch that adds a device
> database in XML format to the /proc filesystem. It collects all information
OH SHIT!! ^^^
Why don't you just add postscript output to /proc?
> about the system's physical devices, creates pers
"Dupuis, Don" wrote:
>
> I have already sent a patch to Alan and Linus on this issue. Linus has
> never responed and Alan said he would look into it in the middle of April.
> Nothing is new at this point
>
> -Original Message-
> From: PhiloVivero [mailto:[EMAIL PROTECTED]]
> Sent: Sunda
Jeff Chua wrote:
>
> On Mon, 23 Apr 2001, Martin Dalecki wrote:
>
> > > > depmod: *** Unresolved symbols in
>/lib/modules/2.4.3-ac11/kernel/drivers/md/lvm-mod.o
>
> try this (after you have applied the patch for lvm 0.9.1_beta7) ...
>
> Jeff
> [[E
Jens Axboe wrote:
>
> On Sat, Apr 21 2001, Ed Tomlinson wrote:
> > Hi,
> >
> > building a kernel with 2.4.3-ac11 and lvm beta7 + vfs_locking_patch-2.4.2 yields:
> >
> > oscar# depmod -ae 2.4.3-ac11
> > depmod: *** Unresolved symbols in
>/lib/modules/2.4.3-ac11/kernel/drivers/md/lvm-mod.o
> > dep
Hello!
The attached patch remove the get_hardblock_size() function entierly
from the kernel. This is due to the fact that this function is
compleatly
unneccessary due to the existance of get_hardsect_size(), which got
introduced to properly encapsulate acesses to the hardsec_size[].
As a side eff
> One thing I certainly miss: DevFS is not mandatory (yet).
That's "only" due to the fact that DevFS is an insanely racy and
instable
piece of CRAP. I'm unhappy it's there anyway...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
Alan Cox wrote:
>
> > If anything I'm a *SERIOUS* production user. And I wouldn't allow
> > *ANYBODY* here to run am explicitly tagged as developement kernel
> > here anyway in an production enviornment. That's what releases are for
> > damn.
> > Or do you think that Linux should still preserve D
Alan Cox wrote:
>
> > So change them as well for a new distribution. What's there problem.
> > There isn't anything out there you can't do by hand.
> > Fortunately so!
>
> So users cannot go back and forward between new and old kernels. Very good.
> Try explaining that to serious production -use
[EMAIL PROTECTED] wrote:
>
> OK - everybody back from San Jose - pity I couldnt come -
> and it is no longer April 1st, so we can continue quarreling
> a little.
>
> Interesting that where I had divided stuff in the trivial part,
> the interesting part and the lot-of-work part we already start
>
Alan Cox wrote:
>
> > Why do you worry about installers? New distro - new kernel - new
> > installer
>
> Because the same code tends to be shared with post install configuration
> tools too.
So change them as well for a new distribution. What's there problem.
There isn't anything out there you
Alan Cox wrote:
>
> > Exactly. It's just that for historical reasons, I think the major for
> > "disk" should be either the old IDE or SCSI one, which just can show more
> > devices. That way old installers etc work without having to suddenly start
> > knowing about /dev/disk0.
>
> They will mos
> what do other vaguely unix-like systems do? does, say, plan9 have a
> better way of dealing with all this?
Yes.
Normal UNIX has as well. For reffernece see: block ver raw
devices on docs.sun.com :-).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
Alan Cox wrote:
>
> > high-end-disks. Rather the reverse. I'm advocating the SCSI layer not
> > hogging a major number, but letting low-level drivers get at _their_
> > requests directly.
>
> A major for 'disk' generically makes total sense. Classing raid controllers
> as 'scsi' isnt neccessaril
Linus Torvalds wrote:
>
> On Tue, 27 Mar 2001, Andre Hedrick wrote:
> >
> > Am I hearing you state you want dynamic device points and dynamic majors?
>
> Yes and no.
>
> We need static structures for user space - from a user perspective it
> makes a ton more sense to say "I want to see all disk
"H. Peter Anvin" wrote:
>
> Alan Cox wrote:
> >
> > > Another example: all the stupid pseudo-SCSI drivers that got their own
> > > major numbers, and wanted their very own names in /dev. They are BAD for
> > > the user. Install-scripts etc used to be able to just test /dev/hd[a-d]
> > > and /dev/
"H. Peter Anvin" wrote:
>
> This is my opinion on the issue. Short summary: "I'm sick of the
> administrative burden associated with keeping dev_t dense."
>
> Linus Torvalds wrote:
> >
> > And let's take a look at /dev. Do a "ls -l /dev" and think about it. Every
> > device needs a unique numbe
Ingo Oeser wrote:
>
> On Tue, Mar 27, 2001 at 03:24:16PM +0200, Martin Dalecki wrote:
> > > @@ -93,6 +95,10 @@
> > > p->uid == 0 || p->euid == 0)
> > > points /= 4;
> > >
> > >
Michel Wilson wrote:
>
> > relative ages. The major flaw in my code is that a sufficiently
> > long-lived
> > process becomes virtually immortal, even if it happens to spring a serious
> > leak after this time - the flaw in yours is that system processes
>
> I think this could easily be fixed i
Jonathan Morton wrote:
>
> Oh and BTW, I think Bit/sqr(seconds) is a perfectly acceptable unit for
> "badness". Think about it - it increases with pigginess and decreases with
> longevity. I really don't see a problem with it per se.
Right it's not a problem pre se, but as you already explain
Jonathan Morton wrote:
>
> >Out of Memory: Killed process 117 (sendmail).
> >
> >What we did to run it out of memory, I don't know. But I do know that
> >it shouldn't be killing one process more than once... (the process
> >should not exist after one try...)
>
> This is a known bug in the Out-of
"Eric W. Biederman" wrote:
>
> Matthew Wilcox <[EMAIL PROTECTED]> writes:
>
> > On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote:
> > > What do you mean by problems 5 years down the road? The real issue is that
> > > this 32-bit block count limit affects composite devices like MD
Jonathan Morton wrote:
>
> >- the AGE_FACTOR calculation will overflow after the system has
> > an uptime of just _3_ days
>
> Tsk tsk tsk...
>
> >Now if you can make something which preserves the heuristics which
> >serve us so well on desktop boxes and add something that makes it
> >also wor
Alan Cox wrote:
>
> > That depends what you mean by "must not". If it's your missile guidance
> > system, aircraft autopilot or life support system, the system must not run
> > out of memory in the first place. If the system breaks down badly, killing
> > init and thus panicking (hence rebooting,
Rik van Riel wrote:
>
> On Sun, 25 Mar 2001, Martin Dalecki wrote:
>
> > Ah... and of course I think this patch can already go directly
> > into the official kernel. The quality of code should permit
> > it. I would esp. request Rik van Riel to have a closer l
Linus Torvalds wrote:
>
> On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote:
> >
> > We need a size, and I am strongly in favor of sizeof(dev_t) = 8;
> > this is already true in glibc.
>
> The fact that glibc is a quivering mass of bloat, and total and utter crap
> makes you suggest that the Linux ker
Stephen Satchell wrote:
>
> At 12:41 AM 3/25/01 +0100, you wrote:
> >If your box is running for example a mail server, and it appears that
> >another process is juste eating the free memory, do you really want to kill
> >the mail server, just because it's the main process and consuming more
> >me
Jonathan Morton wrote:
>
> >Right now my best approximation is to make the OOM test be as optimistic as
> >it is safe to be, and the vm_enough_memory() test as pessimistic as
> >sensible. Expect a test patch to appear on this list soon.
>
> ...and here it is!
>
> This fixes a number of small b
Jeff Garzik wrote:
>
> Also for 2.5, kdev_t needs to go away, along with all those arrays based
> on major number, and be replaced with either "struct char_device" or
> "struct block_device" depending on the device.
>
> I actually went through the kernel in 2.4.0-test days and did this.
> Most k
Benoit Garnier wrote:
>
> Szabolcs Szakacsits wrote :
>
> > But if you start
> > to think you get the conclusion that process killing can't be avoided if
> > you want the system keep running.
>
> What's the point in keeping the OS running if the applications are silently
> killed?
>
> If your
Mike Galbraith wrote:
>
> On Sat, 24 Mar 2001, Doug Ledford wrote:
>
> [snip list of naughty behavior]
>
> > What was that you were saying about "should *never* happen"? Oh, and let's
> Get off your lazy butts and do something about it. Don't work on the
> oom-killer though.. that's only a sy
Doug Ledford wrote:
>
> Horst von Brand wrote:
> >
> > "Christian Bodmer" <[EMAIL PROTECTED]> said:
> >
> > > I can't say I understand the whole MM system, however the random killing
> > > of processes seems like a rather unfortunate solution to the problem. If
> > > someone has a spare minute, m
Martin Dalecki wrote:
>
> I have a constructive proposal:
>
> It would make much sense to make the oom killer
> leave not just root processes alone but processes belonging to a UID
> lower
> then a certain value as well (500). This would be:
>
> 1. Easly managable by
[EMAIL PROTECTED] wrote:
>
> [to various people]
>
> No, ulimit does not work. (But it helps a little.)
> No, /proc/sys/vm/overcommit_memory does not work.
>
> [to Alan]
>
> > Nobody feels its very important because nobody has implemented it.
>
> Yes, that is the right response.
> What can on
SodaPop wrote:
>
> On Fri, 23 Mar 2001, Martin Dalecki wrote:
>
> > SodaPop wrote:
> > >
> > > Rik, is there any way we could get a /proc entry for this, so that one
> > > could do something like:
> >
> > I will respond; NO there is n
[EMAIL PROTECTED] wrote:
>
> Please point me to an Operating System that runs on any commonly available
> platform and fits your requirements.
> Nick
You don't beleve me if I tell you: DOS extender and JVM (Java Virtual
Machine)
-
To unsubscribe from this list: send the line "unsubscribe
I have a constructive proposal:
It would make much sense to make the oom killer
leave not just root processes alone but processes belonging to a UID
lower
then a certain value as well (500). This would be:
1. Easly managable by the admin. Just let oracle/www and analogous users
have a UID low
SodaPop wrote:
>
> Rik, is there any way we could get a /proc entry for this, so that one
> could do something like:
I will respond; NO there is no way for security reasons this is not a
good idea.
> cat /proc/oom-kill-scores | sort +3
-
To unsubscribe from this list: send the line "unsubscrib
Rik van Riel wrote:
>
> On Sat, 23 Mar 2002, Martin Dalecki wrote:
>
> > This is due to the broken calculation formula in oom_kill().
>
> Feel free to write better-working code.
I don't get paid for it and I'm not idling through my days...
-
To unsubscrib
Rik van Riel wrote:
>
> On Sat, 23 Mar 2002, Martin Dalecki wrote:
>
> > Uptime of a process is a much better mesaure for a killing
> > candidate then it's size.
>
> You'll have fun with your root shell, then ;)
You mean the remote one?
> The current
Stephen Clouse wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, Mar 23, 2002 at 01:33:50AM +0100, Martin Dalecki wrote:
> > AMEN! TO THIS!
> > Uptime of a process is a much better mesaure for a killing candidate
> > then it's size.
&
Jonathan Morton wrote:
>
> >> If crashes are routine on this machine, I'd recommend that you take
> >> a serious look at your ram. (or if you're overclocking, don't)
> >
> >Crashes were routine, and I was not overclocking, so I took Mike's
> >advice and bought a new 256MB DIMM. The computer hasn'
Rik van Riel wrote:
>
> On Tue, 13 Mar 2001, Albert D. Cahalan wrote:
>
> > Bloat removal: being able to run without /proc mounted.
> >
> > We don't have "kernel speed". We have kernel-mode screwing around
> > with text formatting.
>
> Sounds like you might want to maintain an external patch
>
Alan Cox wrote:
>
> > My work will concern with the internationalization of Linux
> > So, could anybody tell me what kinds of features should be in the
> > consideration when linux be localized from english to Japanese or chinese,
> > say using 2 bytes character set.
>
> Most of the Linux usersp
"Albert D. Cahalan" wrote:
>
> Geert Uytterhoeven writes:
>
> > - The colors for the 16 color logo are wrong. We used a hack to
> > give the logo its own color palette, but this no longer works
> > as a side effect of a console color map bug being fixed a while
> > ago. The solutio
Peter Samuelson wrote:
>
> [BERECZ Szabolcs]
> > Here is a new syscall. With this you can change the owner of a running
> > procces.
>
> > + if (current->euid)
> > + return -EPERM;
>
> Use capable().
>
> > + p = find_task_by_pid(pid);
> > + p->fsuid = p->euid =
Linus Torvalds wrote:
>
> On Thu, 8 Feb 2001, Rik van Riel wrote:
>
> > On Thu, 8 Feb 2001, Mikulas Patocka wrote:
> >
> > > > > You need aio_open.
> > > > Could you explain this?
> > >
> > > If the server is sending many small files, disk spends huge
> > > amount time walking directory tree and
1 - 100 of 155 matches
Mail list logo
