Sun, Jun 20, 2004 at 02:34:04, andrit wrote about Re: /bin/ls sorting bug?:
And AFAICS, there's no way to tell ls: first sort on time,
then on filename, then on size, etc. This would make a nice addition
though. :)
But there is nice sort command and power of unix.
Don't you remember the
Sorting on nanoseconds too is likely to be more confusing than
useful. Even if we use one of the precious few option letters ls
doesn't use already to add a nanosecond display, most people won't
know about it because they don't care about nanoseconds. They
might care when they notice---as
Discussion on -current, read vs mmap, explained this.
If userland process does pre-fault allocated memory, ng_mmq
appears to be considerably faster than pcap:
# ./benchmark rl0 /dev/mmq15 2
desc rcvd droppedseen totlen ppstime (sec)
mmq 76865 0
Guys,
Hate to be the party-pooper, but this thread is starting to smell a bit odd.
The smell reminds me of something... when I was a kid at school... during
the break ahh, that's it. This thing smells like a bikeshed. :-)
For what it's worth the original patch looked good to me. The
On Mon, Jun 21, 2004 at 09:10:47AM +0100, David Malone wrote:
Sorting on nanoseconds too is likely to be more confusing than
useful. Even if we use one of the precious few option letters ls
doesn't use already to add a nanosecond display, most people won't
know about it because they don't
Hi!
I'm trying to debug kernel panic in 4.10-STABLE.
It is 100% repeatable in my environment but this environment is very
customized and it would be hard for others to reproduce it in my way
(this includes non-standard build of libvgl and mplayer and his libs).
So I want to see what is happening
FreeBSD 5.2.1-RELEASE is easily crashed with tar.
I have a Intel N440BX single CPU Pentium3, dual fxp0, onboard SCSI. 512M ram, and
256M swap. NO programs installed or running - just sshd. I recompiled the kernel,
but I _only removed_ raid controllers and ethernet cards that I didn't need
In a message written on Mon, Jun 21, 2004 at 10:16:49AM +0100, Paul Robinson wrote:
For what it's worth the original patch looked good to me. The nanosecond
patch is fine too. Please, no more intimate discussion of a command line
I'd like to put forth a different argument why the nanosecond
Sergey Lyubka wrote:
Discussion on -current, read vs mmap, explained this.
If userland process does pre-fault allocated memory, ng_mmq
appears to be considerably faster than pcap:
Excellent!
If I connect it directly to ng_ether, the network stack stops working.
The question is - how to make
On Fri, 18 Jun 2004, Ing.Richard Andrysek wrote:
Hi Richard,
I've read your question about SPDIF capture device on freebsd. I am
currently looking for similar device.Have you found such one? Can you
access subcode etc.?
Sorry, I never did find anything immediately useful for SPDIF capture.
I notice the exact same behavior with my wireless Logitechs which were
purchased retail, they all appear to do this. Actually, if you notice
it's always one of the previous keys your pressed, it's as if the repeat
rate is somewhat delayed. This has occured in all OS's for me,
regardless of
On Mon, Jun 21, 2004, David Malone wrote:
Sorting on nanoseconds too is likely to be more confusing than
useful. Even if we use one of the precious few option letters ls
doesn't use already to add a nanosecond display, most people won't
know about it because they don't care about
On 2004-06-21, Leo Bicknell wrote:
While I think the particular sort order (current behavior vrs non
nano patch vrs nano patch) is largely unimportant, I think consistency
is very important. It's quite common to do things like using diff
on the output of commands like ls (indeed, I think
At 10:48 AM +1000 6/22/04, Greg Black wrote:
The output of ls has never been good for reproduceable output
for identical data. It frequently leads to gigantic diffs
in periodic reports which makes them useless, as far as I can
tell. Take the following case:
Hmm. I never thought much about that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 20 Jun 2004 23:29, Eugene Grosbein wrote:
So I want to see what is happening just before my mplayer crashes the
kernel. The problem is that ktracing mplayer does not help as filesystem
can't keep ktrace.out being written just before crash.
On Tue, 22 Jun 2004, Daniel O'Connor wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 20 Jun 2004 23:29, Eugene Grosbein wrote:
So I want to see what is happening just before my mplayer crashes the
kernel. The problem is that ktracing mplayer does not help as filesystem
thanks much for the reply, im going to bring print this and bring it inside to my bsd
box and see what happens. i'll let you know how it works out.
On Sat, 19 Jun 2004 17:00:12 -0600 (MDT)
M. Warner Losh [EMAIL PROTECTED] wrote:
: /*I am trying to figure out how to port over an infrared
Julian Elischer wrote:
I decided to divert ktrace.out to /dev/cuaa0 so another FreeBSD will keep
it. However, ktrace() in src/sys/kern/kern_trace.c does not permit writing
to non-regular file. Why?
As for your problem..
Can you NFS mount? If you have no ethernet you could NFS mount
18 matches
Mail list logo
