Hellmuth Michaelis wrote:
From the keyboard of Juergen Lock:
And the other reason i'm looking at ijppp is ppp compression. It
currently supports deflate (rfc1979) and predictor1 (rfc1978), which
should at least help if the other end is running bsd or linux,
but if your other end is
Imagine: cp file file2, file and file2 reference the same exact blocks,
but modified chunks of file2 would be given their own private blocks.
This is not a microsoft innovation, actually, I believe it was a VMS
innovation. It's called a generational filesystem. the original is
stored,
From the keyboard of Julian Elischer:
today... impressive stuff.) and is someone working on linking i4b
and netgraph?
There will be a netgraph node interface which will link an i4b B-channel
to netgraph. There are no plans from my side to netgraphify the D-channel
part of i4b.
It seems Warner Losh wrote:
In message [EMAIL PROTECTED] Matthew
Jacob writes:
: I gave up on supporting it- too much work for too little gain, IMO.
The same thing happened on the IDE side of things. Even with Soren's
hacks, I never could get it to work well. It worked as well as one
[.]
Currently i'm using ppp instead of mppd mostly just because it supports
deflate compression. I had a look at both mppd and ppp to see how the
mentioned free stac compression would be integrateable and found them
both similar, given they both come from iijppp. It looks like if it were
Alan Batie [EMAIL PROTECTED] wrote:
I just got an onstream scsi tape drive only to discover that I should've
checked the archives because it don't work.
Depends on the drive. If you got an Echo drive (SCxx), you're right.
The ADR drives--yes, they all use ADR tape technology, but confusingly
Imagine: cp file file2, file and file2 reference the same exact blocks,
but modified chunks of file2 would be given their own private blocks.
This is not a microsoft innovation, actually, I believe it was a VMS
innovation. It's called a generational filesystem. the original is
bash and ksh complain about unexpected ';'.
/bin/sh (FreeBSD) thinks it's ok and does nothing.
Which behaviour is more POSIXly correct?
Neither bash nor ksh claim to be particularly POSIX compliant. our
/bin/sh does. I seem to remember POSIX being ambiguous on this one, but
my
On Sun, Mar 05, 2000 at 12:31:30AM -0800, Julian Elischer wrote:
Hellmuth Michaelis wrote:
From the keyboard of Juergen Lock:
And the other reason i'm looking at ijppp is ppp compression. It
currently supports deflate (rfc1979) and predictor1 (rfc1978), which
should at least
I have created several kernel threads that can die after being idle for a
while. I did this by copying the kthread_create() funtion from CURRENT
over to FreeBSD 3.3-Release. Is there a way to remove the zombie threads
after they die or prevent them from creating? Any potential problems in
trying
In article [EMAIL PROTECTED],
Doug Barton [EMAIL PROTECTED] wrote:
Given that Bash in both standard and POSIX mode complains about 'for i
in ; do echo $i; done', I would say that it's not POSIX compatible. What
could/does depend on this behavior "working?"
It works for the realistic
John Polstra wrote:
In article [EMAIL PROTECTED],
Doug Barton [EMAIL PROTECTED] wrote:
Given that Bash in both standard and POSIX mode complains about 'for i
in ; do echo $i; done', I would say that it's not POSIX compatible. What
could/does depend on this behavior "working?"
From: Doug Barton [EMAIL PROTECTED]
Subject: Re: empty lists in for
Date: Sun, 05 Mar 2000 11:39:49 -0800
W Gerald Hicks wrote:
bash and ksh complain about unexpected ';'.
/bin/sh (FreeBSD) thinks it's ok and does nothing.
Which behaviour is more POSIXly correct?
Neither
Doug Barton wrote:
Agreed on all counts. By "this behavior" I was referring to the
example.
Yep -- I was agreeing with you. :-)
John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
W Gerald Hicks wrote:
Even though it's my preferred shell, I certainly wouldn't say
that Bash is any sort of standard, certainly not in the POSIX
sense.
Well, one of Chet's stated goals is to be as POSIX as possible. I agree
that letting the standard speak for itself is a better
From: Doug Barton [EMAIL PROTECTED]
John Polstra already pointed this out, and Bash handles this like you
would expect. There is a difference between expanding an empty list and
trying to expand a list that isn't there.
Convince me that nothing like the following exists in the
ports
W Gerald Hicks wrote:
To me, changing it right now on the eve of -release
would be gratuitous. Later I would be fine with it.
I still prefer /bin/sh being able to handle an empty
literal list but would yield to the desires of others.
I think you misunderstand me. I'm not
In [EMAIL PROTECTED], John Polstra wrote:
In article [EMAIL PROTECTED],
Doug Barton [EMAIL PROTECTED] wrote:
Given that Bash in both standard and POSIX mode complains about 'for i
in ; do echo $i; done', I would say that it's not POSIX compatible. What
could/does depend on this
18 matches
Mail list logo
