On Fri, 6 Aug 1999, Don Lewis wrote:
> On Aug 6, 3:29pm, Sheldon Hearn wrote:
> } Subject: quad_t and portability
> }
> } Hi folks,
> }
> } I want to patch wc(1) so that it uses quad_t instead of u_long. This is
> } necessary if wc(1) is to produce sensible results for files containing
> } more
On Fri, 6 Aug 1999, Don Lewis wrote:
> On Aug 6, 3:29pm, Sheldon Hearn wrote:
> } Subject: quad_t and portability
> }
> } Hi folks,
> }
> } I want to patch wc(1) so that it uses quad_t instead of u_long. This is
> } necessary if wc(1) is to produce sensible results for files containing
> } mor
On Fri, 6 Aug 1999, Daniel O'Connor wrote:
>
> On 06-Aug-99 Wes Peters wrote:
> > Because it's wrong. If you don't believe me, buy a copy of the spec. Why
> > should we waste valuable developer time trying to support mis-configured
> > hardware?
>
> Since when has PC hardware followed the s
On Thu, 5 Aug 1999, Arun Sharma wrote:
> I wonder if so much assembly code is really necessary for FreeBSD. One
> argument for minimal usage of assembly code is that it is easier to code
> non trivial algorithms in C.
No, so much isn't really necessary.
>
> One such example is the scheduler. Si
On Thu, 5 Aug 1999, Jordan K. Hubbard wrote:
> > Mm-hmm. ld -Bshareable as opposed to ar rc.
>
> This demonstrates a superficial understanding of the process, nothing
> more.
I know exactly how an ar archive is made of all the non-PIC .o files and
a ranlib works. I know what happens when ld puts
On Fri, 6 Aug 1999, Daniel O'Connor wrote:
>
> On 06-Aug-99 Wes Peters wrote:
> > Because it's wrong. If you don't believe me, buy a copy of the spec. Why
> > should we waste valuable developer time trying to support mis-configured
> > hardware?
>
> Since when has PC hardware followed the
On Thu, 5 Aug 1999, Arun Sharma wrote:
> I wonder if so much assembly code is really necessary for FreeBSD. One
> argument for minimal usage of assembly code is that it is easier to code
> non trivial algorithms in C.
No, so much isn't really necessary.
>
> One such example is the scheduler. S
On Thu, 5 Aug 1999, Jordan K. Hubbard wrote:
> > Mm-hmm. ld -Bshareable as opposed to ar rc.
>
> This demonstrates a superficial understanding of the process, nothing
> more.
I know exactly how an ar archive is made of all the non-PIC .o files and
a ranlib works. I know what happens when ld put
On Thu, 5 Aug 1999, John Polstra wrote:
> In article ,
> Brian F. Feldman wrote:
> >
> > Mind pointing me to the technical reason why (I'm sure you've explained
> > it before) we can't use the dl* calls in any way without linking
> > against ld-elf.
On Thu, 5 Aug 1999, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Brian F. Feldman <[EMAIL PROTECTED]> wrote:
> >
> > Mind pointing me to the technical reason why (I'm sure you've explained
> > it before) we can't use the dl* calls in
On Thu, 5 Aug 1999, John Polstra wrote:
>
> > My position was (and still is) that for most purposes dynamic
> > linking is a definite advantage, but we should continue to permit
> > static linking for applications that want it (which Sun doesn't).
>
> I generally agree, except I feel that when t
On Thu, 5 Aug 1999, Brian F. Feldman wrote:
Correction:
>
> --- src/sys/i386/linux/linux_util.h.orig Thu Aug 5 18:32:02 1999
> +++ src/sys/i386/linux/linux_util.h Thu Aug 5 19:03:27 1999
> @@ -83,10 +83,17 @@
> int linux_emul_find __P((struct proc *, caddr_t *, con
On Thu, 5 Aug 1999, John Polstra wrote:
>
> > My position was (and still is) that for most purposes dynamic
> > linking is a definite advantage, but we should continue to permit
> > static linking for applications that want it (which Sun doesn't).
>
> I generally agree, except I feel that when
On Thu, 5 Aug 1999, Brian F. Feldman wrote:
Correction:
>
> --- src/sys/i386/linux/linux_util.h.orig Thu Aug 5 18:32:02 1999
> +++ src/sys/i386/linux/linux_util.h Thu Aug 5 19:03:27 1999
> @@ -83,10 +83,17 @@
> int linux_emul_find __P((struct proc *, caddr_t *, con
Thanks to our Peter Holm's stress testing suite, I found a pretty bad
bug in all current emulation (*) code. They all share a common base, and
the problem is in the pathname translation code.
What it amounts to is the inherent assumption that all passed in paths
are valid addresses. This is n
Thanks to our Peter Holm's stress testing suite, I found a pretty bad
bug in all current emulation (*) code. They all share a common base, and
the problem is in the pathname translation code.
What it amounts to is the inherent assumption that all passed in paths
are valid addresses. This is
On Wed, 4 Aug 1999, Doug Rabson wrote:
> The argument for versioning is not simply because the size of ip_number
> might change (it should be a sockaddr) but because other fields might be
> added or removed. To avoid allocating a new syscall whenever this happens,
> the structure should be version
On 4 Aug 1999, Assar Westerlund wrote:
> "Brian F. Feldman" writes:
> > On Tue, 3 Aug 1999, Mike Smith wrote:
> > >
> > > Actually, with interfaces like this you should generally pass a pointer
> > > to the structure in userspace, and stick a vers
On Wed, 4 Aug 1999, Doug Rabson wrote:
> The argument for versioning is not simply because the size of ip_number
> might change (it should be a sockaddr) but because other fields might be
> added or removed. To avoid allocating a new syscall whenever this happens,
> the structure should be versio
On 4 Aug 1999, Assar Westerlund wrote:
> "Brian F. Feldman" <[EMAIL PROTECTED]> writes:
> > On Tue, 3 Aug 1999, Mike Smith wrote:
> > >
> > > Actually, with interfaces like this you should generally pass a pointer
> > > to the structure
On Tue, 3 Aug 1999, Mike Smith wrote:
> > Speaking of the jail() syscall -- it really needs to be revamped a
> > little before people really start using it wholeheartedly. The size
> > of the jail structure needs to be passed in the syscall to allow
> > backwards
> > compatibili
On Tue, 3 Aug 1999, Mike Smith wrote:
> > Speaking of the jail() syscall -- it really needs to be revamped a
> > little before people really start using it wholeheartedly. The size
> > of the jail structure needs to be passed in the syscall to allow backwards
> > compatibility w
On Tue, 3 Aug 1999, Ollivier Robert wrote:
> According to Brian F. Feldman:
> > Jail is in RELENG_3
>[ text explaining my wrongness]
Ack. My memory worked in conjunction with my imagination to trick me.
>
> --
> Ollivier ROBERT -=- FreeBSD: The Pow
On Tue, 3 Aug 1999, Ollivier Robert wrote:
> According to Brian F. Feldman:
> > Jail is in RELENG_3
>[ text explaining my wrongness]
Ack. My memory worked in conjunction with my imagination to trick me.
>
> --
> Ollivier ROBERT -=- FreeBSD: The Power to Serve!
On Tue, 3 Aug 1999, Nik Clayton wrote:
> On Sun, Aug 01, 1999 at 03:00:49PM -0400, Brian F. Feldman wrote:
> > Judging by your description, why don't we use LyX? :) LaTeX sounds about
> > right.
>
> Argh -- contextual sense of humour failure. Smiley not withstanding
On Tue, 3 Aug 1999, Nik Clayton wrote:
> On Sun, Aug 01, 1999 at 03:00:49PM -0400, Brian F. Feldman wrote:
> > Judging by your description, why don't we use LyX? :) LaTeX sounds about
> > right.
>
> Argh -- contextual sense of humour failure. Smiley not withstanding
On Tue, 3 Aug 1999, Ollivier Robert wrote:
>
> It will probably not be very easy putting this into 3.x, considering the
> number of files concerned although the number of lines changed is not that
> big.
Jail is in RELENG_3
> --
> Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...
On Tue, 3 Aug 1999, Ollivier Robert wrote:
>
> It will probably not be very easy putting this into 3.x, considering the
> number of files concerned although the number of lines changed is not that
> big.
Jail is in RELENG_3
> --
> Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL
It's getting better. I don't like that switch (errno) at all. But work on
it some more, make it feature-complete., and I'd love to be able to import
it.
Also, there's a bug:
access: Sun Aug 1 13:46:49 1999
Access: Sun Aug 1 00:09:26 1999
Brian Fundakowski Feldman _ __ ___ __
It's getting better. I don't like that switch (errno) at all. But work on
it some more, make it feature-complete., and I'd love to be able to import
it.
Also, there's a bug:
access: Sun Aug 1 13:46:49 1999
Access: Sun Aug 1 00:09:26 1999
Brian Fundakowski Feldman _ __ ___ _
Judging by your description, why don't we use LyX? :) LaTeX sounds about
right.
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/
Judging by your description, why don't we use LyX? :) LaTeX sounds about
right.
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/
On Sun, 1 Aug 1999, Doug wrote:
> "Jan B. Koum" wrote:
> >
> > On Fri, Jul 30, 1999 at 08:58:09PM -0700, "Jordan K. Hubbard"
> > wrote:
> > > http://features.linuxtoday.com/stories/8191.html
>
> > >From the article:
> >
> > "Linux 2.4 also includes a completely rewritten networking layer."
>
On Sun, 1 Aug 1999, Doug wrote:
> "Jan B. Koum" wrote:
> >
> > On Fri, Jul 30, 1999 at 08:58:09PM -0700, "Jordan K. Hubbard"
><[EMAIL PROTECTED]> wrote:
> > > http://features.linuxtoday.com/stories/8191.html
>
> > >From the article:
> >
> > "Linux 2.4 also includes a completely rewritten netw
On Fri, 30 Jul 1999, Matthew Dillon wrote:
> : But even if you turn off the bpf device, you still have /dev/mem and
> : /dev/kmem to worry about. For that matter, the intruder can still write
> : raw devices. Also, there is another kernel feature called kldload(8).
>
> BTW, I wr
On Fri, 30 Jul 1999, Brian F. Feldman wrote:
> On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
>
> > > There's no good reason to not have bpf in at least the boot disk kernel.
> >
> > It already is. That's not the question under discussion here - we're
On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
> > There's no good reason to not have bpf in at least the boot disk kernel.
>
> It already is. That's not the question under discussion here - we're
> talking about how to make things work in the post-installation boot
> scenario.
When did that hap
If root is compromised, that's the only way bpf can be gotten to by
default. When root's compromised, if no bpf is available, the mem devices
can still be created (if not there) and network queues can be listened to.
And can't IFF_PROMISC be turned on too?
There's no good reason to not have bpf in
Time for this oppressed person to go ln -s H /etc/malloc.conf...
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___
On Fri, 30 Jul 1999, Matthew Dillon wrote:
> : But even if you turn off the bpf device, you still have /dev/mem and
> : /dev/kmem to worry about. For that matter, the intruder can still write
> : raw devices. Also, there is another kernel feature called kldload(8).
>
> BTW, I w
On Fri, 30 Jul 1999, Brian F. Feldman wrote:
> On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
>
> > > There's no good reason to not have bpf in at least the boot disk kernel.
> >
> > It already is. That's not the question under discussion here - we're
On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
> > There's no good reason to not have bpf in at least the boot disk kernel.
>
> It already is. That's not the question under discussion here - we're
> talking about how to make things work in the post-installation boot
> scenario.
When did that ha
If root is compromised, that's the only way bpf can be gotten to by
default. When root's compromised, if no bpf is available, the mem devices
can still be created (if not there) and network queues can be listened to.
And can't IFF_PROMISC be turned on too?
There's no good reason to not have bpf i
Time for this oppressed person to go ln -s H /etc/malloc.conf...
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |__
On Thu, 29 Jul 1999, Sheldon Hearn wrote:
>
>
> On Thu, 29 Jul 1999 00:52:27 -0400, "Brian F. Feldman" wrote:
>
> > If noone has any objections, I will commit this and MFC it in a week or so.
> >
> > --- src/usr.bin/cmp/regular.c.orig Thu Jul
On Thu, 29 Jul 1999, Sheldon Hearn wrote:
>
>
> On Thu, 29 Jul 1999 00:52:27 -0400, "Brian F. Feldman" wrote:
>
> > If noone has any objections, I will commit this and MFC it in a week or so.
> >
> > --- src/usr.bin/cmp/regular.c.orig Thu Jul
On Wed, 28 Jul 1999, Thomas David Rivers wrote:
> >
> > If someone is interested to solve a problem:
> >
> > $ dd if=/dev/zero bs=8848 count=1 of=a 2>/dev/null
> > $ cp a b
> > $ cmp a b 0 0x300
> > Segmentation fault (core dumped)
> > $ cmp a b 0 0x200
> > cmp: EOF on b
> > $ cmp a b 0x300 0
>
On Wed, 28 Jul 1999, Thomas David Rivers wrote:
> >
> > If someone is interested to solve a problem:
> >
> > $ dd if=/dev/zero bs=8848 count=1 of=a 2>/dev/null
> > $ cp a b
> > $ cmp a b 0 0x300
> > Segmentation fault (core dumped)
> > $ cmp a b 0 0x200
> > cmp: EOF on b
> > $ cmp a b 0x300 0
>
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > *rant on*
> > > > Brian, FreeBSD isn't your private playground for playing around, this is
> > > > a group project, and you gotta follow the rules, or you don't get to
> > > > play with the rest of the folks
> > >
> > > The rules don't say "le
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > These were changes that were necessary to make ipfw readable enough that
> > > > I could work with it in this area. They aren't just to clean it up, or
> > > > just for change's sake. They need to stay in.
> > >
> > > C'mon now, re-ording the line
On Wed, 28 Jul 1999, Nate Williams wrote:
> >
> > These were changes that were necessary to make ipfw readable enough that
> > I could work with it in this area. They aren't just to clean it up, or
> > just for change's sake. They need to stay in.
>
> C'mon now, re-ording the lines is *certainly*
On Wed, 28 Jul 1999, Nate Williams wrote:
> > Index: src/sys/netinet/ip_fw.c
> > ===
> > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> > retrieving revision 1.114
> > diff -u -r1.114 ip_fw.c
> > --- ip_fw.c 1999/06/19 18:43:28
Since you've got it in RCS, you shouldn't have any problem adding new
features. How about a selectable display of fields, and ability to put
them in machine-readable (read: no cut required) form? I'd suggest
having a function that would printf "%s: whatever", arg1 for humans
and "whatever" for mach
I need help finishing it. The ipfw.8 manpage isn't quite fixed yet. When
someone will do that, it will be Ready :) But I've attached it!
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > *rant on*
> > > > Brian, FreeBSD isn't your private playground for playing around, this is
> > > > a group project, and you gotta follow the rules, or you don't get to
> > > > play with the rest of the folks
> > >
> > > The rules don't say "l
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > These were changes that were necessary to make ipfw readable enough that
> > > > I could work with it in this area. They aren't just to clean it up, or
> > > > just for change's sake. They need to stay in.
> > >
> > > C'mon now, re-ording the lin
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > Implementing it is the easy part, making sure it's the right thing to do
> > > is the hard part.
> >
> > Well, the easy part is done, except for raising limits. Look:
> > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> > ipfw: 1 Deny ICMP:8.
On Wed, 28 Jul 1999, Nate Williams wrote:
> >
> > These were changes that were necessary to make ipfw readable enough that
> > I could work with it in this area. They aren't just to clean it up, or
> > just for change's sake. They need to stay in.
>
> C'mon now, re-ording the lines is *certainly
On Wed, 28 Jul 1999, Nate Williams wrote:
> > Index: src/sys/netinet/ip_fw.c
> > ===
> > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> > retrieving revision 1.114
> > diff -u -r1.114 ip_fw.c
> > --- ip_fw.c 1999/06/19 18:43:28
Since you've got it in RCS, you shouldn't have any problem adding new
features. How about a selectable display of fields, and ability to put
them in machine-readable (read: no cut required) form? I'd suggest
having a function that would printf "%s: whatever", arg1 for humans
and "whatever" for mac
I need help finishing it. The ipfw.8 manpage isn't quite fixed yet. When
someone will do that, it will be Ready :) But I've attached it!
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!
On 28 Jul 1999, Dag-Erling Smorgrav wrote:
> "Brian F. Feldman" writes:
> > My point was that it's not a very important thing to do to give out
> > FreeBSD CDs like BSD/OS gives out trial versions of their wares.
>
> Yes, it is. Try doing an FTP install acr
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > Implementing it is the easy part, making sure it's the right thing to do
> > > is the hard part.
> >
> > Well, the easy part is done, except for raising limits. Look:
> > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> > ipfw: 1 Deny ICMP:8
On 28 Jul 1999, Dag-Erling Smorgrav wrote:
> "Brian F. Feldman" <[EMAIL PROTECTED]> writes:
> > My point was that it's not a very important thing to do to give out
> > FreeBSD CDs like BSD/OS gives out trial versions of their wares.
>
> Yes, it is. Try
On Tue, 27 Jul 1999, Nate Williams wrote:
> > If it will get ALL of you to give it a rest, how about:
> > per-rule logging limits
> > logging limit raising
> > logging limit resetting
> > Which would all NOT affect the statistics?
>
> We need more input from people who use the code, t
On Tue, 27 Jul 1999, Nate Williams wrote:
> > If it will get ALL of you to give it a rest, how about:
> > per-rule logging limits
> > logging limit raising
> > logging limit resetting
> > Which would all NOT affect the statistics?
>
> We need more input from people who use the code,
If it will get ALL of you to give it a rest, how about:
per-rule logging limits
logging limit raising
logging limit resetting
Which would all NOT affect the statistics?
I am, yes, suggesting I will implement it.
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
If it will get ALL of you to give it a rest, how about:
per-rule logging limits
logging limit raising
logging limit resetting
Which would all NOT affect the statistics?
I am, yes, suggesting I will implement it.
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
On Tue, 27 Jul 1999, Jordan K. Hubbard wrote:
> > But we can install from a single downloaded boot floppy, over the
> > Internet, which is better.
>
> 1. Irrelevant, since most people who want to try BSD/OS out probably
>aren't concerned about how FreeBSD installs itself; they're
>simply
On Tue, 27 Jul 1999, Jordan K. Hubbard wrote:
> > But we can install from a single downloaded boot floppy, over the
> > Internet, which is better.
>
> 1. Irrelevant, since most people who want to try BSD/OS out probably
>aren't concerned about how FreeBSD installs itself; they're
>simply
On Tue, 27 Jul 1999, Sheldon Hearn wrote:
>
>
> On Tue, 27 Jul 1999 08:19:38 -0400, "Brian F. Feldman" wrote:
>
> > Getting rid of as much as possible, gradually, is a Very Good Thing;
> > this is how we get stability and performance improvements.
>
>
On Tue, 27 Jul 1999, Soren Schmidt wrote:
> It seems Dag-Erling Smorgrav wrote:
> >
> > I move that we replace GNU grep in our source tree with this
> > implementation, once it's been reviewed by all concerned parties.
>
> Go for it, the more GNU stuff we nuke the better :)
>
> -S?ren
>
Geez,
On Tue, 27 Jul 1999, Sheldon Hearn wrote:
>
>
> On Tue, 27 Jul 1999 08:19:38 -0400, "Brian F. Feldman" wrote:
>
> > Getting rid of as much as possible, gradually, is a Very Good Thing;
> > this is how we get stability and performance improvements.
>
>
On Tue, 27 Jul 1999, Soren Schmidt wrote:
> It seems Dag-Erling Smorgrav wrote:
> >
> > I move that we replace GNU grep in our source tree with this
> > implementation, once it's been reviewed by all concerned parties.
>
> Go for it, the more GNU stuff we nuke the better :)
>
> -Søren
>
Geez
On Tue, 27 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:
> I'd like to grope around inside a .deb file, which has been created on a
> debian Linux box. Do we have any nifty tools for this, like rpm2cpio?
I would look for something called "alien", which supposedly can conver
On Mon, 26 Jul 1999, Warner Losh wrote:
> In message
> "Brian
> F. Feldman" writes:
> : But we can install from a single downloaded boot floppy, over the
> : Internet, which is better.
>
> Is that still true? I thought we went back to two floppies to do
>
On Tue, 27 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:
> I'd like to grope around inside a .deb file, which has been created on a
> debian Linux box. Do we have any nifty tools for this, like rpm2cpio?
I would look for something called "alien", which supposedly can conve
On Mon, 26 Jul 1999, Warner Losh wrote:
> In message
> <[EMAIL PROTECTED]> "Brian
> F. Feldman" writes:
> : But we can install from a single downloaded boot floppy, over the
> : Internet, which is better.
>
> Is that still true? I thought we went bac
On Mon, 26 Jul 1999, Matthew Dillon wrote:
>
> :That doesn't mean we shouldn't allow people to have an unsophisticated setup,
> :just because a sophisticated one is available. It would be useful to have
> :a per-firewall-rule counter, decrement it on each match if logging and
> :set, and be able
On Mon, 26 Jul 1999, Rayson Ho wrote:
> Hi,
>
> I am not sure whether this is known to this list or
> not, but here is the URL for ordering:
>
> http://www.bsdi.com/products/evalcd/
>
But we can install from a single downloaded boot floppy, over the
Internet, which is better.
>
>
> ___
On Mon, 26 Jul 1999, Sheldon Hearn wrote:
>
>
> On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote:
>
> > You could start with "WinEXE".
>
> Save game file formats, not game executables. You think WinEXE tops my
> pcgames suggestion?
No. How about "savegames"? The Quake 2 format in there w
On Mon, 26 Jul 1999, Matthew Dillon wrote:
>
> :Instead of zeroing it, how about raising the logging limit to (current +
> :whatever the limit was)
> :
> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> : gr...@freebsd.org _ __ ___ | _ ) __| \
>
> The way
Instead of zeroing it, how about raising the logging limit to (current +
whatever the limit was)
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.
On Mon, 26 Jul 1999, Matthew Dillon wrote:
>
> :That doesn't mean we shouldn't allow people to have an unsophisticated setup,
> :just because a sophisticated one is available. It would be useful to have
> :a per-firewall-rule counter, decrement it on each match if logging and
> :set, and be able
On Mon, 26 Jul 1999, Rayson Ho wrote:
> Hi,
>
> I am not sure whether this is known to this list or
> not, but here is the URL for ordering:
>
> http://www.bsdi.com/products/evalcd/
>
But we can install from a single downloaded boot floppy, over the
Internet, which is better.
>
>
> __
On Mon, 26 Jul 1999, Sheldon Hearn wrote:
>
>
> On Mon, 26 Jul 1999 23:30:08 +0200, Mark Murray wrote:
>
> > You could start with "WinEXE".
>
> Save game file formats, not game executables. You think WinEXE tops my
> pcgames suggestion?
No. How about "savegames"? The Quake 2 format in there
On Mon, 26 Jul 1999, Matthew Dillon wrote:
>
> :Instead of zeroing it, how about raising the logging limit to (current +
> :whatever the limit was)
> :
> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> : [EMAIL PROTECTED] _ __ ___ | _ ) __| \
>
> The way
Instead of zeroing it, how about raising the logging limit to (current +
whatever the limit was)
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www
On Sun, 25 Jul 1999, Mark Newton wrote:
> Ronald G. Minnich wrote:
>
>
> > But thanks for the note. I just now realized that if I add a private name
> > space to v9fs (which is easy), and then turn on user mounts, user
> > processes can have private name spaces on freebsd!
>
> I can't wait t
On Sun, 25 Jul 1999, Mark Newton wrote:
> Ronald G. Minnich wrote:
>
>
> > But thanks for the note. I just now realized that if I add a private name
> > space to v9fs (which is easy), and then turn on user mounts, user
> > processes can have private name spaces on freebsd!
>
> I can't wait
On Sat, 24 Jul 1999, Sheldon Hearn wrote:
>
> Hi folks,
>
> I plan to mention in the comments for each service in /etc/services, the
> latest RFC describing the service. I also plan to mention in the manpage
> for services(5) the e-mail address to which requests for "How do I get
> the RFCs" sho
On Sat, 24 Jul 1999, Sheldon Hearn wrote:
>
> Hi folks,
>
> I plan to mention in the comments for each service in /etc/services, the
> latest RFC describing the service. I also plan to mention in the manpage
> for services(5) the e-mail address to which requests for "How do I get
> the RFCs" sh
On 21 Jul 1999, Dag-Erling Smorgrav wrote:
> What kinds of BSDI binaries are we supposed to be able to run? I
> haven't had any luck getting *any* BSDI binaries to run on my (very
> recent) 4.0-CURRENT box. I have a handful of BSDI binaries, some of
> which are identified as:
>
> d...@des ~/yes/b
On 21 Jul 1999, Dag-Erling Smorgrav wrote:
> What kinds of BSDI binaries are we supposed to be able to run? I
> haven't had any luck getting *any* BSDI binaries to run on my (very
> recent) 4.0-CURRENT box. I have a handful of BSDI binaries, some of
> which are identified as:
>
> des@des ~/yes/b
On Wed, 21 Jul 1999, Peter Jeremy wrote:
> John-Mark Gurney wrote:
> >and even then, I don't believe in filling sockaddr_in w/ bzero, I
> >believe in using getsockaddr on it so that you actually get all the
> >fields filled out properly...
>
> % man getsockaddr
> No manual entry for getsockaddr
On Wed, 21 Jul 1999, Peter Jeremy wrote:
> John-Mark Gurney <[EMAIL PROTECTED]> wrote:
> >and even then, I don't believe in filling sockaddr_in w/ bzero, I
> >believe in using getsockaddr on it so that you actually get all the
> >fields filled out properly...
>
> % man getsockaddr
> No manual e
On Mon, 19 Jul 1999, Jordan K. Hubbard wrote:
> > website (http://www.freebsd.org/~green/FreeBSD-68k.txt). In about two
> > weeks I'll have a spare Macintosh IIsi and would like to have a run at
> > FreeBSD on it. So, to the point, where can I get it? :)
>
> I'd say that's a question for Grant
On Mon, 19 Jul 1999, Jordan K. Hubbard wrote:
> > website (http://www.freebsd.org/~green/FreeBSD-68k.txt). In about two
> > weeks I'll have a spare Macintosh IIsi and would like to have a run at
> > FreeBSD on it. So, to the point, where can I get it? :)
>
> I'd say that's a question for Grant
On Mon, 19 Jul 1999, John Polstra wrote:
> In article ,
> Brian F. Feldman wrote:
> >
> [GNU getopt]
> > If you give me documentation on it, I'll implement it for the BSD libc.
>
> Note, we already have GNU getopt in the source tree in libiberty (in
> two d
On Mon, 19 Jul 1999, Warner Losh wrote:
> In message
> Per Lundberg writes:
> : I know it isn't standard. But it works well, and is used by a lot of
> : programs. Perhaps it should have been put in another library than libc,
> : though. Actually, I'd better suggest this to the GNU people right a
101 - 200 of 337 matches
Mail list logo
