Re: Replacement for grep(1) (part 2)

-BEGIN PGP SIGNED MESSAGE- So, Matt, I understand that you think that the folks who are want to turn off overcommit are looking to hang themselves, but how much does it cost to sell them the rope? Would adding the sysctl to turn off overcommit be a costly, time-consuming hunk of work, o

Re: Replacement for grep(1) (part 2)

On Tue, 13 Jul 1999 15:44:40 -0700 (PDT) Matthew Dillon wrote: > So far nobody has been able to justify any good reasons for adding it > to the system. I'm sorry, but just throwing out worst-case theories > is not a good justification, nor is throwing embedded systems into the

Re: more amd hangs: problem really in syslog?

On Tue, 13 Jul 1999, Mike Smith wrote: > 'siobi' is someone trying to open the serial console, for whatever > reason. Without knowing who it was that was stuck there, it's hard to > guess what is going on. D'uh, sorry. Long day. It was amd that was hung in the siobi state. No way to clea

Re: Replacement for grep(1) (part 2)

:So, Matt, I understand that you think that the folks who are want to :turn off overcommit are looking to hang themselves, but how much does :it cost to sell them the rope? : :Would adding the sysctl to turn off overcommit be a costly, :time-consuming hunk of work, or a three-line patch? If it's

Re: more amd hangs: problem really in syslog?

On Tue, 13 Jul 1999, Matthew Dillon wrote: > Comment the whole thing out, kill -HUP the syslogd (or kill and restart > it), and see if amd still locks up. Ok, now I think I get it. You want me to enable syslog'ing in amd, then do what you're talking about here. I will try this fir

Re: Replacement for grep(1) (part 2)

Matthew Dillon writes: > :> ram and 512MB of swap (4MB of swap in use), but the kernel reports over > :> 3 GB of VM assigned to processes. That's a fairly lightly loaded machine. > : > :What you say is generally true; however, the problem is that *you* > :are making implicit assumptions about what

Re: Replacement for grep(1) (part 2)

> So, Matt, I understand that you think that the folks who are want to > turn off overcommit are looking to hang themselves, but how much does > it cost to sell them the rope? The issue here is that "turning off overcommit" isn't just a switch. There are a lot of other things that you're likely

Re: Replacement for grep(1) (part 2)

: :Well, all I can say is: : : I'm sure glad you don't have any influence over the code : base I run. : :-- Jason R. Thorpe I'm sure the feeling is mutual. More to the point, I really seriously doubt that any of the core developers would consider this idea either

Re: Replacement for grep(1) (part 2)

On Tue, 13 Jul 1999 16:16:07 -0700 Mike Smith wrote: > Matt's point, which he's not making by virtue of talking too much, is > that you can't make a "no overcommit" system behave like an "overcommit" > system, and most people are used to the sort of things that the latter > makes practica

Re: Replacement for grep(1) (part 2)

On Tue, 13 Jul 1999 16:24:53 -0700 (PDT) Matthew Dillon wrote: > I'm sure the feeling is mutual. More to the point, I really seriously > doubt that any of the core developers would consider this idea either > because it's been rejected in the past and, so far, nobody has offere

Re: Replacement for grep(1) (part 2)

:(Mike Smith ) :Matt's point, which he's not making by virtue of talking too much, is :that you can't make a "no overcommit" system behave like an "overcommit" :system, and most people are used to the sort of things that the latter :makes practical. Heh heh.

Re: Replacement for grep(1) (part 2)

:On Tue, 13 Jul 1999 16:24:53 -0700 (PDT) : Matthew Dillon wrote: : : > I'm sure the feeling is mutual. More to the point, I really seriously : > doubt that any of the core developers would consider this idea either : > because it's been rejected in the past and, so far, nobody has

Re: Replacement for grep(1) (part 2)

> On Tue, 13 Jul 1999 16:16:07 -0700 > Mike Smith wrote: > > > Matt's point, which he's not making by virtue of talking too much, is > > that you can't make a "no overcommit" system behave like an "overcommit" > > system, and most people are used to the sort of things that the latter > >

Re: Replacement for grep(1) (part 2)

On Tue, 13 Jul 1999 16:29:50 -0700 Mike Smith wrote: > You can make the "overcommit or not overcommit" option a switch, but > the consumers of the system (may) need to change their behaviour as > well. I never said they wouldn't have to. -- Jason R. Thorpe To Unsubscribe: sen

Re: Replacement for grep(1) (part 2)

> On Tue, 13 Jul 1999 16:29:50 -0700 > Mike Smith wrote: > > > You can make the "overcommit or not overcommit" option a switch, but > > the consumers of the system (may) need to change their behaviour as > > well. > > I never said they wouldn't have to. "Making it just a switch" does not

Re: a BSD identd

> Doug wrote: > > John Polstra wrote: > >> > >> Are you sure? If you simply don't run an identd, the queries will > >> get an instant connection refused error. That's even faster than > >> sending back a bogus response. > > > > Many daemons that request ident, and almost all IRC daemons >

Re: Replacement for grep(1) (part 2)

>: >:Well, all I can say is: >: >: I'm sure glad you don't have any influence over the code >: base I run. >: >:-- Jason R. Thorpe > >I'm sure the feeling is mutual. More to the point, I really seriously >doubt that any of the core developers would consider this idea ei

Re: Replacement for grep(1) (part 2)

Matthew Dillon scribbled this message on Jul 13: > FreeBSD's swap subsystem has a basic limitation of 4 swap areas. This > is due to the design of the interleaving algorithms. Increasing this > number is simple, but it results in phenominally more kernel memory > getting wired. W

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

:> And disallowing overcommit also does not give applications the *choice* :> of dealing gracefully, because they often cannot deal with the :> situation where they might be refused a reasonable request for memory. : :That's objectively false. The application could do something useful

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

On Tue, 13 Jul 1999 16:56:26 -0700 (PDT) Matthew Dillon wrote: > You have to consider the probability of an event occuring, not just > the possibility that the event might occur. If the probability is > one in a million years, then it is not something you need to worry > a

Re: Replacement for grep(1) (part 2)

> On Tue, 13 Jul 1999 15:53:43 -0700 (PDT), Matthew Dillon said: > ... a situation which will never occur if you are managing the memory > through your own custom library. Therefore not relevant. Hm. It's misunderstanding. I don't agree with you about the following point. T

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

> On Tue, 13 Jul 1999 16:56:26 -0700 (PDT) > Matthew Dillon wrote: > > > You have to consider the probability of an event occuring, not just > > the possibility that the event might occur. If the probability is > > one in a million years, then it is not something you need to

Swap subsystem overhead (was Re: Replacement for grep(1) (part 2))

:hmmm... so this means that on my home server where I have: :Device 1K-blocks UsedAvail Capacity Type :/dev/od0b 26214431176 23084012%Interleaved :/dev/da1b 39321631136 361952 8%Interleaved :/dev/da2b 26214431072 23094412%Inter

Re: a BSD identd

On Mon, 12 Jul 1999 15:12:49 -0400, "Brian F. Feldman" wrote: > It's "out with the bad, in with the good." Pidentd code is pretty > terrible. Hi Brian, I let your comment above go at the time that you said it and I waited for Kevin Day to substantiate similar claims. Kevin very kindly took the

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

: :On Tue, 13 Jul 1999 16:56:26 -0700 (PDT) : Matthew Dillon wrote: : : > You have to consider the probability of an event occuring, not just : > the possibility that the event might occur. If the probability is : > one in a million years, then it is not something you need to worry

Re: Replacement for grep(1) (part 2)

-BEGIN PGP SIGNED MESSAGE- Matthew Dillon wrote: >I said: >:So, Matt, I understand that you think that the folks who are want to >:turn off overcommit are looking to hang themselves, but how much does >:it cost to sell them the rope? > >I'm guessing that a simple implementation would

Re: Replacement for grep(1) (part 2)

:Hm. It's misunderstanding. : :I don't agree with you about the following point. :Thus, the situation might happen. : :>Give me a shell and I can crash any machine. If you are assuming :>hostile users, you cannot assume that your magic overcommit protection :>will save your server. S

Re: Setting up a firewall with dynamic IPs

> I was checking out the firewall setup in /etc/rc.firewall, and noticed that > the simple example relied on a fixed IP address for the external interface. I > don't know ahead of time what IP address is going to be allocated to me > before > I dial up. Would it be possible to specify an interf

Re: Replacement for grep(1) (part 2)

> On Tue, 13 Jul 1999 17:25:21 -0700 (PDT), Matthew Dillon said: > With today's modern high capacity disk drives, a properly configured > multi-user system will have enough swap that running it out is difficult > to say the least. That's wrong. Please remember that you sa

Re: Replacement for grep(1) (part 2)

:> On Tue, 13 Jul 1999 17:25:21 -0700 (PDT), : Matthew Dillon said: : :> With today's modern high capacity disk drives, a properly configured :> multi-user system will have enough swap that running it out is difficult :> to say the least. : :That's wrong. :Please remember tha

Re: Replacement for grep(1) (part 2)

> On Tue, 13 Jul 1999 17:53:10 -0700 (PDT), Matthew Dillon said: > You keep on saying that users can run the system out of swap > easily, and I've tried to point out to you that it isn't quite > as easy as you believe (and I've used a real-life example to > show my poi

Re: Setting up a firewall with dynamic IPs

Thanks for every one's help - I now have it working nicely. It's amazing what you discover when RTFMing. Oddly enough, running nmap with the Christmas tree scan (after I've allowed only smtp & ssh to be connected to) gives the following - # ./nmap -v -v -sX foo Starting nmap V. 2.12 by Fyodor

Re: Reading CIS from kernel?

> The Xircom ethernet driver needs to read/write PCCARD attribute memory from > its probe routine, in order to identify the type of card and to beat ... > then making crdread() and crdwrite() (in /sys/pccard/pccard.c) > non-static and calling them directly from the driver code would be an > easy w

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

: :> Has your simulation ever been kicked by the kernel due to lack of :> swap space? : :I already said so. Please at least pretend to read what I wrote :before replying. : :There is a big difference here between a piddling web server and a :1000-hour simulation. If the web server goes do

RE: Setting up a firewall with dynamic IPs

> Stephen Hocking wrote: > you discover when RTFMing. Oddly enough, running nmap with > the Christmas tree > scan (after I've allowed only smtp & ssh to be connected to) > gives the > following - > > Initiating FIN,NULL, UDP, or Xmas stealth scan against foo.bar.com > Nmap run completed -- 1

Re: Reading CIS from kernel?

On Tue, Jul 13, 1999 at 06:22:03PM -0700, David O'Brien wrote: > [about cdread()/cdwrite() in /sys/pccard/pcccard.c] > > Since no one has repsonded to this querry, I will be un-staticizing these > so they will be available to drivers. This is going to be for both -current and MFC'd back into -sta

Re: Setting up a firewall with dynamic IPs

:Thanks for every one's help - I now have it working nicely. It's amazing what :you discover when RTFMing. Oddly enough, running nmap with the Christmas tree :scan (after I've allowed only smtp & ssh to be connected to) gives the :following - : :# ./nmap -v -v -sX foo : :Starting nmap V. 2.12 by

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

>The point is, the OS should have provided *some* mechanism to insure >that the long-running process wasn't affected. It didn't. That's a >clear failure of the OS to provide a reasonable environment for this >type of computing. > >Whether this should be solved by switching to a no-overcommit poli

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

:> swap. How much swap is on this system, by the way? : :I could just as rightfully argue that you're blaming a failure of the :OS on the sysadmin. Fiddling with limits is all fine and dandy, but :it's not even close to flexible enough. Consider, for example, the :specific case of testing a

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

: I've long felt that the best solution to problems like this is a per-user :swap space quota. This gives admins a knob to manage the allocation of swap :space while still allowing overcommit. The downside is that it doesn't provide :a graceful way for a program to recover from it's overconsumpt

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

On 14-Jul-99 Jason Thorpe wrote: > On Tue, 13 Jul 1999 16:56:26 -0700 (PDT) > Matthew Dillon wrote: > > > You have to consider the probability of an event occuring, not just > > the possibility that the event might occur. If the probability is > > one in a million years, then

Re: a BSD identd

We don't _need_ pidentd anymore. It will load down a system more than the inetd's implementation of ident will. Therefore, pidentd should be phased out. Other than that, pidentd should be using http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm. Brian Fundakowski Feldman _

Re: Replacement for grep(1) (part 2)

is there some reason why whether or not to overcommit can't be a kernel compile time option? Or that a process can signal its desire to not get SIGKILL by registering a non-default SIGDANGER (which we'd have to create) handler ala AIX? ] Train travel features AC outlets with no take-off rest

Re: Replacement for grep(1) (part 2)

On Tue, 13 Jul 1999, Matthew Dillon wrote: > There are other ways. For example, even if a user account is resource > limited, root processes (such as sendmail, popper, identd, and so forth) > are not. Attacks against these servers generally result in very high > loads and sometim

Re: Replacement for grep(1) (part 2)

On Tue, 13 Jul 1999, Matthew Dillon wrote: > Jason, I am using real life situations to demonstrate my point. You are > perfectly welcome to use your own REAL-LIFE situations to demonstrate > yours. It is the real-life application that matters, not a worst-case > nightmare theory

Re: Reading CIS from kernel?

In message <19990713182203.a68...@nuxi.com> "David O'Brien" writes: : Since no one has repsonded to this querry, I will be un-staticizing these : so they will be available to drivers. No. Please don't. This is the first I've seen this. There will be another cis reading interface as part of the

Re: Reading CIS from kernel?

In message <19990713210337.h85...@remarq.com> Ade Lovett writes: : This is going to be for both -current and MFC'd back into -stable, yes? The interface for doing this I'll be merging back into -stable. Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers"

Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)

On Thu, 8 Jul 1999 09:54:42 +0100 (BST), Doug Rabson said: dfr> If I understand this correctly, you are suggesting that we program timer0 dfr> so that we only take interrupts when a finetimer is due to fire? If so, dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me d

Boot messages on console in 3.2

Hi ... I'm trying to get a 3.2-STABLE to boot via the serial console. I can get the "boot: " rompt and loader to display to the serial console, but after the 9 second delay it continues to boot but no output is generated to the screen (device probes etc.). After the boot has completed, the logi

Re: Replacement for grep(1) (part 2)

"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote: > > I can add it to the list of reasons I don't use it then I guess ;-). > > Whatever. The operating system you use also does it. How terribly tedious. Cheers Jon -- \/ Jon Ribbens / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECT

Setting up a firewall with dynamic IPs

I was checking out the firewall setup in /etc/rc.firewall, and noticed that the simple example relied on a fixed IP address for the external interface. I don't know ahead of time what IP address is going to be allocated to me before I dial up. Would it be possible to specify an interface (tun0)

Re: Boot messages on console in 3.2

>I'm trying to get a 3.2-STABLE to boot via the serial console. > >I can get the "boot: " rompt and loader to display to the serial >console, but after the 9 second delay it continues to boot but >no output is generated to the screen (device probes etc.). > >After the boot has completed, the login

Re: Replacement for grep(1) (part 2)

Alfred Perlstein <[EMAIL PROTECTED]> wrote: > You're browsing with netscape and It hits about 32megs in size, > you click on a multimedia object and netscape execs a helper app. vfork() > you also have to consider a program wishing to make sparse use > of its address space, without overcommit it

Re: Replacement for grep(1) (part 2)

> You're browsing with netscape and It hits about 32megs in size, > you click on a multimedia object and netscape execs a helper app. If the system has real vfork(2) like NetBSD, this is not problem. > you also have to consider a program wishing to make sparse use > of its address space, without

Re: bin/12578: `` subshell taints PWD

Sheldon Hearn wrote: > > On Mon, 12 Jul 1999 18:37:13 GMT, Niall Smart wrote: > > > The patch appended seems to fix this, I'd like someone familiar > > with sh to review it though, since this may be symptomatic of > > a general problem with command substitution. > > As I understand your patch,

Re: a BSD identd

"Brian F. Feldman" wrote: > On Mon, 12 Jul 1999, Sheldon Hearn wrote: > > On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: > > > > > Finally, Brian might want to search the bugtraq archives before > > > he commits anything. There have been quite a few identd related > > > discussions, and it w

Re: Setting up a firewall with dynamic IPs

On Tue, 13 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > I was checking out the firewall setup in /etc/rc.firewall, and noticed that > the simple example relied on a fixed IP address for the external interface. I > don't know ahead of time what IP address is going to be

Why 'dd' does not seek over 'char' devs (specifically raw disk partitions).

Hi, i have a question. Why 'dd' does not seek over 'char' devs (specifically raw disk partitions). My point is, when a disk develops problems, sometimes it is possible to recover nearby sectors e.g. using dd, and seeking to the right block. However running dd over the char device (rwd*) takes fo

Re: Setting up a firewall with dynamic IPs

On Tue, Jul 13, 1999 at 10:16:32PM +0930, Kris Kennaway wrote: > On Tue, 13 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > > > I was checking out the firewall setup in /etc/rc.firewall, and noticed that > > the simple example relied on a fixed IP address for the external i

Re: Setting up a firewall with dynamic IPs

In message , Kris Kennaway wrote : } On Tue, 13 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote } : } } > I was checking out the firewall setup in /etc/rc.firewall, and noticed } > that the simple example relied on a fixed IP add

Re: a BSD identd

On 13 Jul 1999, Ville-Pertti Keinonen wrote: > > [EMAIL PROTECTED] (Brian F. Feldman) writes: > > > It's "out with the bad, in with the good." Pidentd code is pretty terrible. > > The only security concerns with my code were wrt FAKEID, and those were > > mostly fixed (mostly meaning that a sym

Re: Setting up a firewall with dynamic IPs

On Tue, 13 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > I was checking out the firewall setup in /etc/rc.firewall, and noticed that > the simple example relied on a fixed IP address for the external interface. I > don't know ahead of time what IP address is going to be

Re: Replacement for grep(1) (part 2)

On Tue, 13 Jul 1999, Noriyuki Soda wrote: > > You're browsing with netscape and It hits about 32megs in size, > > you click on a multimedia object and netscape execs a helper app. > > If the system has real vfork(2) like NetBSD, this is not problem. > > > you also have to consider a program wis

Re: Setting up a firewall with dynamic IPs

On Tue, 13 Jul 1999, Jon Hamilton wrote: > } You could probably do it from /etc/ppp/ppp.linkup, which knows your IP > } address as MYADDR. But if you just have asingle machine on the end of the > } dialup then > > You can do it as the original poster was thinking as well by specifying the > "r

Re: a BSD identd

On Tue, 13 Jul 1999, Niall Smart wrote: > "Brian F. Feldman" wrote: > > > On Mon, 12 Jul 1999, Sheldon Hearn wrote: > > > On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: > > > > > > > Finally, Brian might want to search the bugtraq archives before > > > > he commits anything. There have been

Re: Replacement for grep(1) (part 2)

> On Tue, 13 Jul 1999 10:11:14 -0400 (EDT), "Brian F. Feldman" <[EMAIL PROTECTED]> said: >> > you also have to consider a program wishing to make sparse use >> > of its address space, without overcommit it becomes impossible. >> >> SVR4 has MAP_NORESERVE option for mmap(2) for this.

Re: Why 'dd' does not seek over 'char' devs (specifically raw diskpartitions).

On Tue, 13 Jul 1999, Luigi Rizzo wrote: > Hi, i have a question. > > Why 'dd' does not seek over 'char' devs (specifically raw disk partitions). Not all character devices support seeking. So, we work with the LCD... Sorry, I don't like this either. It would be better, maybe, just to fix charact

Re: Why 'dd' does not seek over 'char' devs (specifically raw disk

> > Hi, i have a question. > > > > Why 'dd' does not seek over 'char' devs (specifically raw disk partitions). > > Not all character devices support seeking. So, we work with the LCD... > Sorry, I don't like this either. It would be better, maybe, just to fix > character devices. couldn't we fi

Re: Why 'dd' does not seek over 'char' devs (specifically raw disk

On Tue, 13 Jul 1999, Luigi Rizzo wrote: > > > Hi, i have a question. > > > > > > Why 'dd' does not seek over 'char' devs (specifically raw disk partitions). > > > > Not all character devices support seeking. So, we work with the LCD... > > Sorry, I don't like this either. It would be better, ma

Which device should I make with this error?

During a make release for 3.2-RELEASE I get the following error: Making the regular boot floppy. Compressing doc files... sh -e /usr/src/release/scripts/doFS.sh -s mfsroot /R/stage /mnt 2880 /R/stage/m fsfd 8000 minimum2 vnconfig: open: Device not configured *** Error code 1 Stop. *** Error cod

Re: Replacement for grep(1) (part 2)

Jon Ribbens writes: > > Because memory (as in *real* memory, either RAM or swap) is > > allocated on-demand. So you can allocate any amount of virtual > > memory that the system can possibly provide you, even though you'll > > run out of memory much earlier, because other resources are also > > co

Re: Which device should I make with this error?

On Tue, 13 Jul 1999, eT wrote: > During a make release for 3.2-RELEASE I get the following error: > > Making the regular boot floppy. > Compressing doc files... > sh -e /usr/src/release/scripts/doFS.sh -s mfsroot /R/stage /mnt 2880 > /R/stage/m > fsfd 8000 minimum2 > vnconfig: open: Device not

Re: Which device should I make with this error?

Lo and Behold, eT said: > During a make release for 3.2-RELEASE I get the following error: > > vnconfig: open: Device not configured > *** Error code 1 > > What does this mean and how do I fix it? It means you don't have any vnode devices configured in your kernel. What, you ask, is a vnode di

Re: bin/12578: `` subshell taints PWD

Niall Smart wrote in list.freebsd-hackers: > As I understand it most builtins will not spawn a new shell > when they are used in command substitution: > > niall% echo `echo $$` $$ > 20354 20354 > niall% Actually, that example doesn't prove anything. :-) $ echo `echo $$` $$ 8376 8376 $ e

Can only mount system read-only?

Hey All, It was suggested that I email this problem to this list since for the past weeks (on and off) I can get no resolution from the questions list. I have Debian Linux and FreeBSD system. Debian being my main OS right now, but I think FreeBSD would an upgrade. While in Debian I re-partitio

Re: bin/12578: `` subshell taints PWD

On Tue, 13 Jul 1999 18:13:42 +0200, Oliver Fromme wrote: > Command substitution certainly has to spawn a subshell, even > for built-in commands, because otherwise you could modify > parent shell variables within command substitutions. But isn't that exactly what's happening here, where PWD is

Re: Why 'dd' does not seek over 'char' devs (specifically raw disk

In article <[EMAIL PROTECTED]>, Brian F. Feldman <[EMAIL PROTECTED]> wrote: > On Tue, 13 Jul 1999, Luigi Rizzo wrote: > > > couldn't we first try lseek and only do the reads on char devs where > > the lseek fails ? > > lseek() won't usually fail unless it's something like EBADF. It merely > sets

Re: Replacement for grep(1) (part 2)

On Tue, 13 Jul 1999 10:11:14 -0400 (EDT) "Brian F. Feldman" <[EMAIL PROTECTED]> wrote: > > SVR4 has MAP_NORESERVE option for mmap(2) for this. > > So, default behaivour don't have to be overcommitment. > > Isn't that just like mmap()ing then mlock()ing the range? That would > keep it in c

RE: more amd hangs: in _start()

On Tue, 13 Jul 1999, Ladavac Marino wrote: > I don't know if your diagnosis was in jest, Yes it was, but thank you for asking. :) I should have known better than to attempt subtle humor at the end of a long, tiring day. Doug -- On account of being a democracy and run by the peopl

Re: Replacement for grep(1) (part 2)

This topic has been rehashed a thousand times. What it comes down to is that if you want to disallow overcommit, you have to multiply the amount of swap space in the system relative to current levels in order to get the same performance limits as you had before. If you don't,

Re: bin/12578: `` subshell taints PWD

Sheldon Hearn wrote in list.freebsd-hackers: > On Tue, 13 Jul 1999 18:13:42 +0200, Oliver Fromme wrote: > > > Command substitution certainly has to spawn a subshell, even > > for built-in commands, because otherwise you could modify > > parent shell variables within command substitutions. >

Re: Replacement for grep(1) (part 2)

On Tue, 13 Jul 1999 11:13:49 -0700 (PDT) Matthew Dillon <[EMAIL PROTECTED]> wrote: > SysV was totally and utterly broken in regards to swap allocation. The > only major operating system that used it as a base was IRIX and SGI > found out very quickly that pre-reserving swap is a

Re: bin/12578: `` subshell taints PWD

On Tue, 13 Jul 1999, Oliver Fromme wrote: > > But isn't that exactly what's happening here, where PWD is being tainted > > by the commands evaluated within the substitution? > > Yes, I'd call that a bug which should be fixed. > The manpage clearly says: > > "The shell expands the command

Re: 3.2-STABLE not stable but panicy?

As Mike Smith wrote ... > This is typically symptomatic of poor CPU cooling; all of a sudden you Well, it wasn't the cooler, that was just fine. The CPU was quite cool (it has a big, good heatsink & fan) > are running the CPU at full power 100% of the time, rather than sitting > in an HLT ins

Re: Replacement for grep(1) (part 2)

But I have a valid point: can we do something better than posting a SIGKILL to the largest process? Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://

Re: Replacement for grep(1) (part 2)

On Tue, Jul 13, 1999 at 02:47:20PM -0400, Brian F. Feldman wrote: > But I have a valid point: can we do something better than posting a SIGKILL > to the largest process? I think AIX sends all running processes a magic signal (SIGDANGER?) which indicates that the system is short of resources, and

Re: Replacement for grep(1) (part 2)

:But I have a valid point: can we do something better than posting a SIGKILL :to the largest process? : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ : [EMAIL PROTECTED] _ __ ___ | _ ) __| \ We could have the ability to mark processes as being more or les

Re: Why 'dd' does not seek over 'char' devs (specifically raw disk

On Tue, 13 Jul 1999, John Polstra wrote: > In article <[EMAIL PROTECTED]>, > Brian F. Feldman <[EMAIL PROTECTED]> wrote: > > On Tue, 13 Jul 1999, Luigi Rizzo wrote: > > > > > couldn't we first try lseek and only do the reads on char devs where > > > the lseek fails ? > > > > lseek() won't usual

Re: a BSD identd

In message <[EMAIL PROTECTED]>, "Bria n F. Feldman" writes: >On 13 Jul 1999, Ville-Pertti Keinonen wrote: > >> >> [EMAIL PROTECTED] (Brian F. Feldman) writes: >> >> > It's "out with the bad, in with the good." Pidentd code is pretty terrible >. >> > The only security concerns with my code were w

Re: Replacement for grep(1) (part 2)

> > We could have the ability to mark processes as being more or less > preferable as kill candidates. I'm not sure I really care anymore, > though... there is so much disk space available now that it is fairly > difficult to run the system out of swap space. I don't think I've

Re: Replacement for grep(1) (part 2)

On Tue, 13 Jul 1999, Matthew Dillon wrote: > > :But I have a valid point: can we do something better than posting a SIGKILL > :to the largest process? > : > : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > : [EMAIL PROTECTED] _ __ ___ | _ ) __| \ > > We c

Re: Replacement for grep(1) (part 2)

"Brian F. Feldman" <[EMAIL PROTECTED]> writes: > But I have a valid point: can we do something better than posting a SIGKILL > to the largest process? If I remember correctly, AIX sends a signal to all processes asking them to free up memory. (Processes ignore this signal by default.) If nobody

Re: a BSD identd

On Tue, 13 Jul 1999, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, "Bria > n F. Feldman" writes: > >On 13 Jul 1999, Ville-Pertti Keinonen wrote: > > > >> > >> [EMAIL PROTECTED] (Brian F. Feldman) writes: > >> > >> > It's "out with the bad, in with the good." Pidentd code is pretty terrible

Re: Replacement for grep(1) (part 2)

:> We could have the ability to mark processes as being more or less :> preferable as kill candidates. I'm not sure I really care anymore, :> though... there is so much disk space available now that it is fairly :> difficult to run the system out of swap space. I don't think I'v

Re: a BSD identd

On Tue, Jul 13, 1999 at 03:12:51PM -0400, Brian F. Feldman wrote: > > Why not actually store the fake ID in a symbolic link? That way you just > > do a readlink(), which would be safer, neater and faster than reading a > > file. A user can set up a fake ID with something like: > > > > ln

Re: Replacement for grep(1) (part 2)

[cc list trimmed because it was getting ... insane, and it's not like this is a critical point. It's just beating up a topic which has been beaten up by many others.] Matthew Dillon <[EMAIL PROTECTED]> writes: > Thus it makes little sense to try to disallow overcommit. It gains you > abs

[Off Topic] ODBC and yahoo

Couple of questions which are pretty much off topic 1) Does anyone know of a way to talk to a remote oracle server via odbc or oci? Access is required specifically under apache and mod_perl or php, but we've spent a couple of man-days looking for straightforward answers and found none:( 2)

Re: a BSD identd

In article <[EMAIL PROTECTED]>, Ian Dowse <[EMAIL PROTECTED]> wrote: > > Why not actually store the fake ID in a symbolic link? That way you just > do a readlink(), which would be safer, neater and faster than reading a > file. A user can set up a fake ID with something like: > > ln

Re: Replacement for grep(1) (part 2)

On Tue, 13 Jul 1999, David Malone wrote: > I think AIX sends all running processes a magic signal (SIGDANGER?) > which indicates that the system is short of resources, and if things > don't improve real soon then it sends a SIGKILL. Not that I'd suggest > that AIX does things the right way... FY

Re: Replacement for grep(1) (part 2)

:> have to allocate anyway if we were to actually disallow overcommits! But :> with overcommits allowed, your box will never come close to using that :> much swap. : :This may be a decent answer for the workstation world, but it's not so :good for more restricted systems. Further, y

<    1   2   3   >