Sheldon Hearn [EMAIL PROTECTED] writes:
In this case, the implementation we'll be introducing will introduce a
performance loss, not a gain.
Can you document that?
As far as stability goes, there's a loss
involved _if_ passing the GNU grep regression tests is
Hello !
I am interesting about idea of directories man?/{i386|alpha}.
By their names I can understand that they are directories there
platform specific man pages for certain man section will be stored.
As I see there are only hard-linked manpages in man?/i386 directories. But
it's interesting --
On Tue, 27 Jul 1999 22:20:40 MST, "David O'Brien" wrote:
My advice would be to submit his PR to Chris Demtrito(sp?), file's
maintainer. Then import NetBSD's file (Chris is a NetBSD guy).
Hmmm. So file(1) is a contrib candidate?
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL
An application I use quite often requires me to reverse the lines in the
file to get the desired output.
'tail -r' appears to be very inefficient in it's use of mmap(). It mmap's
the entire file in, which encourages the kernel to swap out the rest of the
system to keep pages of the input file
On Tue, 27 Jul 1999 22:20:40 MST, "David O'Brien" wrote:
My advice would be to submit his PR to Chris Demtrito(sp?), file's
maintainer. Then import NetBSD's file (Chris is a NetBSD guy).
You may want to verify this. I'm pretty sure that Christos Zoulas
(another NetBSD guy) maintains
On Wed, 28 Jul 1999 12:03:25 +0100, Andy Doran wrote:
You may want to verify this. I'm pretty sure that Christos Zoulas
(another NetBSD guy) maintains file(1): [EMAIL PROTECTED]
Confirmed. Other than the mistaken name, I think David obsoleted further
discussion, since it really is the best
Hi ...
I previously mailed the same error ... and then I thought
it was a "miss-corrolation" between kernel sources and
userland. Since then I built a SNAP of 990726 sources
and tried the same thing and the error occured again .
Same sources used for the compile of the kernel and userlevel
"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 doing an FTP install across a 28k8 or 33k6 modem some
time.
DES
--
Dag-Erling Smorgrav - [EMAIL
On Wed, Jul 28, 1999 at 03:30:58AM -0400, Dag-Erling Smorgrav wrote:
There seems to be at least one dependency on GNU grep in
/ports/Mk/bsd.port.mk where the -F argument is used.
-F is implemented.
I saw that, but had assumed the semantics were different. I should
have read the read
I have a problem compiling of files needed for network boot on a FreeBSD
3.2-Release.
As it was writen in handbook, I have to compile nb8390.com, nb3c509.com,
nb8390.rom, nb3c509.rom files to perform boot over network. But during
compile a I get the following error:
Andrew Gordon [EMAIL PROTECTED] writes:
The application for which I need this is to support capture from the bktr
driver onto the screen (ie. so that you can watch TV without X). With the
above hack and a small (100-line) program it works very nicely - far
tidier than installing X just for
Dima wrote:
I have a problem compiling of files needed for network boot on a FreeBSD
3.2-Release.
as I understand I need this file (scrt0.o) because netboot makes *com
files only from a.out files, not from ELF. In sources I found where is
this file compiled - /usr/src/lib/csu. But it will
On Wed, 28 Jul 1999, Brian F. Feldman 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?
Separate statistics/logging counters is fine, but i don't
I'd suggest that you use "tac" from GNU textutils.
Charles
-Original Message-
From: Kevin Day [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 28, 1999 3:09 AM
To: [EMAIL PROTECTED]
Subject: Replace/rewrite reverse.c for tail(1)
An application I use quite often requires me to reverse
Krzysztof Krawczyk wrote:
When I do:
echo "blah blah" /dev/ttyp1
text "blah blah" appear in virtual terminal ttyp1, but only as a text of
"message". I need ttyp1 count those datas as a "command typed by hand",
not just a text displayed in this term as info. I must transport lots of
data
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.0 127.0.0.1 127.0.0.1 out via lo0
ipfw: limit 2 reached on
In message [EMAIL PROTECTED] "David O'Brien" writes:
: Before importing, it must display a version number of 1.0 (or drop the
: version number). This is not Linux where everything is version 0.xy.
For a long time the new boot loader was in the tree with a version
0.xx...
Warner
To
Hi folks,
Could someone have a look at the patch proposed on PR 12852? I
understand the motivation, since it seems reasonable to me that ferror()
should return EBADF after an attempt to read from stdout. At the moment,
ferror() returns 0 after an attempt to read from stdout.
Thanks,
Sheldon.
My advice would be to submit his PR to Chris Demtrito(sp?), file's
You may want to verify this. I'm pretty sure that Christos Zoulas
(another NetBSD guy) maintains file(1): [EMAIL PROTECTED]
My major Duh!! If Christos sees this thread, my apologies. There is no
excuse for me not
I expect that there is a very good reason why this shouldn't be done,
but could it be possible to implement two different algorithms/code
dependant on the size of the file being grepped?
Mark Dickey
[EMAIL PROTECTED]
Daniel C. Sobral wrote:
James Howard wrote:
Due to the discussion of
Sheldon Hearn wrote:
Could someone have a look at the patch proposed on PR 12852? I
understand the motivation, since it seems reasonable to me that ferror()
should return EBADF after an attempt to read from stdout. At the moment,
ferror() returns 0 after an attempt to read from stdout.
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 doing an FTP install across a 28k8 or 33k6 modem
On Tue, 27 Jul 1999, Brian F. Feldman wrote:
If it will get ALL of you to give it a rest, how about:
per-rule logging limits
This has been needed for some time now. Also, please don't forget
the oft-repeated request to have seperate accounting and logging counters
so that you
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.0 127.0.0.1 127.0.0.1 out via lo0
ipfw: limit
I hacked this together last night. The only GNU code I looked at was the
Linux stat(1u) man page. (A man page is forthcoming, especially if there is
some interest in using this implementation.) The code is also available at
http://www.kagekaze.org/stat.c
Regards,
--Keith Stevenson--
--
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!
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 1.114
+++ ip_fw.c 1999/07/28 06:29:07
@@ -106,6
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
-hackers,
Could someone who knows write/writev(2) take a quick look at docs/10512.
In essence, writev(2) can fail with ENOBUFS if (and I quote from the PR)
if you "exhaust writev'able buffer space". This doesn't mean a great
deal to me, and I'm hoping one of you can take a look at come up
On Tue, Jul 27, 1999 at 10:58:08PM -0700, David O'Brien wrote:
Lets help these people out. How about adding this to 3.3's RELEASE notes
and a pointer from our website? (maybe also
http://www.freebsd.org/handbook/install.html)
If you can give me text, I'll mark it up and add it.
N
--
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 1.114
@@ -302,14 +303,15 @@
struct ifnet *rif, struct ifnet *oif)
{
if (ip) {
+ struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip-ip_hl);
+ struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip-ip_hl);
+ struct icmp *const icmp = (struct icmp
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* not
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* not necessary to work.
That's true. I sure
On Wed, Jul 28, 1999 at 04:01:10PM -0400, Brian F. Feldman wrote:
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
On Wed, 28 Jul 1999, Brian F. Feldman wrote:
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.
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*
*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 "leave the code that you work with in a bigger mess than
when you
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* not necessary to work.
That's
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 "leave the code that
In the kernel config file you can use symbolic names for the various
COM ports, IO_COM1, IO_COM2, and so on.
These seem be defined in sys/isa/isareg.h.
If you want to configure FreeBSD to boot from a serial console you have
to set BOOT_COMCONSOLE_PORT in /etc/make.conf -- you can't use
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
Doug [EMAIL PROTECTED] wrote:
The more complete the feature set, the better
off we are for my money.
Someone offering money? Quick, who's got the donations hat... :-)
Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Wes Peters wrote:
I have written man pages for aio_write, aio_error, aio_return,
aio_cancel, aio_suspend, and lio_listio. They are in my ~ on
freefall if anyone would like to review them. I have also edited
aio_read.2 and aio.h to correct minor problems, if you would like
to review those
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
cmp: EOF on a
Jean-Marc
--
Jean-Marc ZucconiPGP Key: finger [EMAIL
I am wading through the portalfs and nullfs source, but I am desperately
lost. I would love to be able to find out who would be willing to help out
with questions. I feel I would be spamming far too many people by just sending
to -hackers. Some of the topics I am curious about are general
On Thu, Jul 29, 1999 at 01:59:45AM +0900, Daniel C. Sobral wrote:
Sorry, but a simplistic analysis like that just won't cut for grep.
The algorithmic complexity is highly relevant here. Try this:
Algorithmic complexity!?!
It's a freaking grep application. There is no freaking algorithmic
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
cmp: EOF on a
Jean-Marc
I've seen a similar problem when doing cmp with
On Wed, Jul 28, 1999 at 02:42:35PM -0600, Nate Williams wrote:
The code is *NO* more readable by you re-ordering lines and changes
whitespace.
It's white!
No, dammit, it's beige!
Fuck you, I said it's white!
Beige!
White!
I dunno, I guess for some people the distinction's actually
:I am wading through the portalfs and nullfs source, but I am desperately
:lost. I would love to be able to find out who would be willing to help out
:with questions. I feel I would be spamming far too many people by just sending
:to -hackers. Some of the topics I am curious about are general
On Wed, Jul 28, 1999 at 02:40:19PM -0600, Nate Williams wrote:
Or is this Linux, where we don't give a rip and whatever the current
patch does to the rest of the tree is fine, since the more code we have
the better?
Nate, you know damn well that's not true. You're complaining about
three
On Wed, 28 Jul 1999, Matthew Dillon wrote:
Ouch. I don't think anyone understands the VOP stuff completely. It's
a big mess -- which is why it's going to be rewritten later this year.
Your best bet is to study the implementation of the UFS/FFS filesystem.
well, i'd do v9fs
On Wed, 28 Jul 1999, David E. Cross wrote:
I am wading through the portalfs and nullfs source, but I am desperately
lost. I would love to be able to find out who would be willing to help out
with questions. I feel I would be spamming far too many people by just sending
to -hackers.
Might
On 28 Jul 1999, Dag-Erling Smorgrav wrote:
Andrew Gordon [EMAIL PROTECTED] writes:
The application for which I need this is to support capture from the bktr
driver onto the screen (ie. so that you can watch TV without X). With the
above hack and a small (100-line) program it works very
: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 26 Jul 1999, Dag-Erling Smorgrav wrote:
Sheldon Hearn [EMAIL PROTECTED] writes:
I plan to mention in the comments for each service in /etc/services, the
latest RFC describing the service.
Good idea.
H... I'm not sure what this gets us. Wouldn't it be better to
place this
: Sheldon Hearn [EMAIL PROTECTED] writes:
: I plan to mention in the comments for each service in /etc/services, the
: latest RFC describing the service.
:
: Good idea.
:
: H... I'm not sure what this gets us. Wouldn't it be better to
:place this kind of information in the man page
On 29-Jul-99 Andrew Gordon wrote:
On 28 Jul 1999, Dag-Erling Smorgrav wrote:
Andrew Gordon [EMAIL PROTECTED] writes:
The application for which I need this is to support capture from the bktr
driver onto the screen (ie. so that you can watch TV without X). With the
above hack and a
According to Keith Stevenson:
Sure, I can work on that. It would be helpful if you could include a few
sample outputs that I could work from.
You may also want to look at the builtin stat(1) function in zsh too. 3.1.5+
only, I don't think 3.1.4 had it. BTW 3.1.6 now pretty close to release.
Because of licensing restrictions in our product, we are unable to ship with
any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I
saw tac, and agree that it is faster for this specific use)
Any VM people wanna pipe up and make a suggestion so that I may make up a
patch?
:Because of licensing restrictions in our product, we are unable to ship with
:any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I
:saw tac, and agree that it is faster for this specific use)
:
:Any VM people wanna pipe up and make a suggestion so that I may make up a
:Because of licensing restrictions in our product, we are unable to ship with
:any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I
:saw tac, and agree that it is faster for this specific use)
:
:Any VM people wanna pipe up and make a suggestion so that I may make up a
:Wow, that's interesting. While I never looked at the code, I *thought* I was
:able to measure a speed boost in a certain large embedded application I'm
:working on, with adding some madvise()'s in to mmap'ed files. (Streaming
:video madvise'ed with MADV_SEQUENTIAL seemed to be slightly faster,
various researchers and early-adopters, all of which can go to the
KAME site and grab the patches to 3.2-stable if they want to play now,
today. If we haven't done a good enough job of making that clear and
are suffering from defections to other *BSDs because of this, then we
just need to
Hi!
I have created a script to integrate FreBSD 3.2, KAME and PAO.
As a result I have the following source trees:
- FREEBSD+KAME(make world is working :-)
- FREEBSD+PAO (haven't tested yet, no conflicts)
- FREEBSD+KAME+PAO(haven't tested yet, 2 minor conflicts)
Once I have
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, to make sure
Brian F. Feldman gr...@freebsd.org writes:
That's true. I'd like to see the replacement grep do mmaping of the
input files if it doesn't already, as that would speed it up.
Shouldn't be too hard to implement, the way file operations are
abstracted. Patches? :)
DES
--
Dag-Erling Smorgrav -
Sheldon Hearn sheld...@uunet.co.za writes:
In this case, the implementation we'll be introducing will introduce a
performance loss, not a gain.
Can you document that?
As far as stability goes, there's a loss
involved _if_ passing the GNU grep regression tests is
Tim Vanderhoek vand...@ecf.utoronto.ca writes:
Have you run your systems with J-grep as a replacement for GNU grep
for a while (making sure nothing breaks)?
Yes.
There seems to be at least one dependency on GNU grep in
/ports/Mk/bsd.port.mk where the -F argument is used.
-F is implemented.
Hello !
I am interesting about idea of directories man?/{i386|alpha}.
By their names I can understand that they are directories there
platform specific man pages for certain man section will be stored.
As I see there are only hard-linked manpages in man?/i386 directories. But
it's interesting --
On Tue, 27 Jul 1999 22:20:40 MST, David O'Brien wrote:
My advice would be to submit his PR to Chris Demtrito(sp?), file's
maintainer. Then import NetBSD's file (Chris is a NetBSD guy).
Hmmm. So file(1) is a contrib candidate?
Ciao,
Sheldon.
To Unsubscribe: send mail to
An application I use quite often requires me to reverse the lines in the
file to get the desired output.
'tail -r' appears to be very inefficient in it's use of mmap(). It mmap's
the entire file in, which encourages the kernel to swap out the rest of the
system to keep pages of the input file in
On Tue, 27 Jul 1999 22:20:40 MST, David O'Brien wrote:
My advice would be to submit his PR to Chris Demtrito(sp?), file's
maintainer. Then import NetBSD's file (Chris is a NetBSD guy).
You may want to verify this. I'm pretty sure that Christos Zoulas
(another NetBSD guy) maintains file(1):
On Wed, 28 Jul 1999 12:03:25 +0100, Andy Doran wrote:
You may want to verify this. I'm pretty sure that Christos Zoulas
(another NetBSD guy) maintains file(1): chris...@zoulas.com.
Confirmed. Other than the mistaken name, I think David obsoleted further
discussion, since it really is the
Hi ...
I previously mailed the same error ... and then I thought
it was a miss-corrolation between kernel sources and
userland. Since then I built a SNAP of 990726 sources
and tried the same thing and the error occured again .
Same sources used for the compile of the kernel and userlevel
Brian F. Feldman gr...@freebsd.org 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 across a 28k8 or 33k6 modem some
time.
DES
--
Dag-Erling Smorgrav -
On Wed, Jul 28, 1999 at 03:30:58AM -0400, Dag-Erling Smorgrav wrote:
There seems to be at least one dependency on GNU grep in
/ports/Mk/bsd.port.mk where the -F argument is used.
-F is implemented.
I saw that, but had assumed the semantics were different. I should
have read the read the
I have a problem compiling of files needed for network boot on a FreeBSD
3.2-Release.
As it was writen in handbook, I have to compile nb8390.com, nb3c509.com,
nb8390.rom, nb3c509.rom files to perform boot over network. But during
compile a I get the following error:
/usr/src/sys/i386/boot/netboot
Andrew Gordon a...@arg1.demon.co.uk writes:
The application for which I need this is to support capture from the bktr
driver onto the screen (ie. so that you can watch TV without X). With the
above hack and a small (100-line) program it works very nicely - far
tidier than installing X just
Dima wrote:
I have a problem compiling of files needed for network boot on a FreeBSD
3.2-Release.
as I understand I need this file (scrt0.o) because netboot makes *com
files only from a.out files, not from ELF. In sources I found where is
this file compiled - /usr/src/lib/csu. But it will
HI everybody.
I'm having a problem writing a multi-threaded application.
As I understand from the mans, calls to read and write are synchronized through
file-locks. Having looked through the source for libc_r I noticed that calls to
printf and fprintf are also synchronized.
The question is -
On Wed, 28 Jul 1999, Brian F. Feldman 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?
Separate statistics/logging counters is fine, but i don't
If it's of any use, I have 300 tun devices in my home development
machine and have no problems with sendmail, but I have a tulip card
(de) rather than an Intel and haven't every ``ifconfig delete''d it.
Hi ...
I previously mailed the same error ... and then I thought
it was a
On Tue, 27 Jul 1999, Julian Elischer wrote:
a system wide limit and each rule's logging counter individually resetable
back to 0.
So, what's your vote?
... Joe
I vote for this too.
Henk.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of
I'd suggest that you use tac from GNU textutils.
Charles
-Original Message-
From: Kevin Day [mailto:toa...@dragondata.com]
Sent: Wednesday, July 28, 1999 3:09 AM
To: hack...@freebsd.org
Subject: Replace/rewrite reverse.c for tail(1)
An application I use quite often requires me to
Krzysztof Krawczyk wrote:
When I do:
echo blah blah /dev/ttyp1
text blah blah appear in virtual terminal ttyp1, but only as a text of
message. I need ttyp1 count those datas as a command typed by hand,
not just a text displayed in this term as info. I must transport lots of
data between
And then ... securelevel == 3 I think it is better NOT to permit
'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile
faster to avoid DoS
The real issue we are dealing with is what happens at securelevel == 3.
What you are saying is that people shouldn't be allowed to modify
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.0 127.0.0.1 127.0.0.1 out via lo0
ipfw: limit 2 reached on
In message 19990727214451.a66...@dragon.nuxi.com David O'Brien writes:
: Before importing, it must display a version number of 1.0 (or drop the
: version number). This is not Linux where everything is version 0.xy.
For a long time the new boot loader was in the tree with a version
0.xx...
Hi folks,
Could someone have a look at the patch proposed on PR 12852? I
understand the motivation, since it seems reasonable to me that ferror()
should return EBADF after an attempt to read from stdout. At the moment,
ferror() returns 0 after an attempt to read from stdout.
Thanks,
Sheldon.
My advice would be to submit his PR to Chris Demtrito(sp?), file's
You may want to verify this. I'm pretty sure that Christos Zoulas
(another NetBSD guy) maintains file(1): chris...@zoulas.com.
My major Duh!! If Christos sees this thread, my apologies. There is no
excuse for me not
James Howard wrote:
Due to the discussion of speed, I have been looking at it and it is really
slow. Even slower than I thought and I was thinking it was pretty slow.
So using gprof, I have discovered that it seems to spend a whole mess of
time in grep_malloc() and free(). So I pulled
I expect that there is a very good reason why this shouldn't be done,
but could it be possible to implement two different algorithms/code
dependant on the size of the file being grepped?
Mark Dickey
m...@bestweb.net
Daniel C. Sobral wrote:
James Howard wrote:
Due to the discussion of speed,
Sheldon Hearn wrote:
Could someone have a look at the patch proposed on PR 12852? I
understand the motivation, since it seems reasonable to me that ferror()
should return EBADF after an attempt to read from stdout. At the moment,
ferror() returns 0 after an attempt to read from stdout.
On 28 Jul 1999, Dag-Erling Smorgrav wrote:
Brian F. Feldman gr...@freebsd.org 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 across a 28k8 or 33k6 modem some
On Tue, 27 Jul 1999, Brian F. Feldman wrote:
If it will get ALL of you to give it a rest, how about:
per-rule logging limits
This has been needed for some time now. Also, please don't forget
the oft-repeated request to have seperate accounting and logging counters
so that you can
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.0 127.0.0.1
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.0 127.0.0.1 127.0.0.1 out via lo0
ipfw: limit 2
I hacked this together last night. The only GNU code I looked at was the
Linux stat(1u) man page. (A man page is forthcoming, especially if there is
some interest in using this implementation.) The code is also available at
http://www.kagekaze.org/stat.c
Regards,
--Keith Stevenson--
--
Keith
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!
1 - 100 of 141 matches
Mail list logo
