"Brian F. Feldman" 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 - d...@yes.no
To
Sheldon Hearn 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 important.
Do y
Tim Vanderhoek 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.
DES
--
Dag-Erling
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 -- w
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 majord...@freeb
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 fil
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 be
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
bin
"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 across a 28k8 or 33k6 modem some
time.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
T
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 re
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 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 this purpose on
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 w
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 - w
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, b
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 "miss-c
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
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 rev
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
> d
> 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 reach
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...
Wa
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.
T
> > > 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 pull
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 sp
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" 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.
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 ca
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.
> > > > 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 l
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!
> 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 mach
-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 with
-hackers,
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 us
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
--
[in
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
> > > @@ -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 =
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*
> > > 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 t
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 sta
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
> > > *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
>
> > > > > 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 n
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
> 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
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.
> >
> > > > In particular, the changes I pointed out are not 'cleanups', but style
> > > > changes.
> > >
> > > When you make code readable, it's a cleanup.
> >
> > The code is *NO* more readable by you re-ordering lines and changes
> > whitespace.
>
> This is so very objective.
That's why it consi
Doug 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 majord...@freebsd.org
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 t
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 j...@fre
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 fs-sty
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 do
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
mea
: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 fs
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
:> The code is *NO* more readable by you re-ordering lines and changes
:> whitespace.
:...
:
:.
Sounds like one of many arguments I've had with various people
who insist on nitpicking and critiqing to death tiny little
itsy bitsy inconsistancies that no normal person would car
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 v9f
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.
M
On 28 Jul 1999, Dag-Erling Smorgrav wrote:
> Andrew Gordon 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
: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 *cer
On 26 Jul 1999, Dag-Erling Smorgrav wrote:
> Sheldon Hearn 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 info
:> Sheldon Hearn 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 that you sugg
On 29-Jul-99 Andrew Gordon wrote:
> On 28 Jul 1999, Dag-Erling Smorgrav wrote:
>
>> Andrew Gordon 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 (10
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?
Kevi
: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
: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, but
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
>
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 PROTECT
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 fi
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
bi
"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 r
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 <[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
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
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,
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 "miss-
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the bod
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
>
> 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 reac
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 Unsubscri
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 ch
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 pul
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.
1 - 100 of 149 matches
Mail list logo
