i have a little program, aux/cpuid
perhaps this would be better in /dev/cons/cpuid ?
just my 2ยข
-Steve
perhaps this would be better in /dev/cons/cpuid ?
doppio% ls '#P'
'#P/archctl'
'#P/cputype'
'#P/ioalloc'
'#P/iob'
'#P/iol'
'#P/iow'
'#P/irqalloc'
'#P/realmode'
'#P/realmodemem'
doppio% cat '#P/cputype'
AMD64 1802
doppio% cat '#P/archctl'
cpu AMD64 1802 pge
pge on
coherence mb586
cmpswap
On 25/01/2010 01:45, Akshat Kumar wrote:
what are some suggested ways to copy just
the rest of the file, without starting all over?
dd
On 23/01/2010 19:01, Rudolf Sykora wrote:
Maybe it only
happens once in 1000 times, but in that 0.1% of the time, my
finger coming down on the return key accidentally hits the up
arrow and the timing just so happens that I rerun the previous
command instead of the one I just typed, sometimes
doppio% cat '#P/archctl'
Isn't archctl more concerned with things specifically of interest to the
kernel vm system? That was always my impression. Adding CPUID related
output to #P/cputype seems more logical.
On Mon Jan 25 10:00:19 EST 2010, lyn...@orthanc.ca wrote:
i have a little program, aux/cpuid, that gets cpuid
information for x86 processors. clearly it's not going
to run on an arm or mips. is there a standard
trick for preventing such a program from being
built (and failing)? the
On Mon Jan 25 12:03:08 EST 2010, fors...@terzarima.net wrote:
perhaps this would be better in /dev/cons/cpuid ?
i don't think so.
doppio% cat '#P/cputype'
AMD64 1802
doppio% cat '#P/archctl'
cpu AMD64 1802 pge
pge on
coherence mb586
cmpswap cmpswap486
i8253set on
none of that was
On 29 Dec 2009, at 11:53 pm, erik quanstrom wrote:
i'm getting spurious echo in 9term on average about 2/3 of
the time. this example sees the spurious echo every time.
programs like bash that eat cooked input don't seem to suffer
the same fate.
Yes, on both OS X and Linux. I find I'm most
x86 assembly doesn't often assemble with an
arm assembler. :-)
Oh come on. Everything you need to make this work is already there.
On Mon Jan 25 13:11:49 EST 2010, rminn...@gmail.com wrote:
On Mon, Jan 25, 2010 at 9:54 AM, erik quanstrom quans...@quanstro.net wrote:
; aux/cpuid -v
AuthenticAMD
; aux/cpuid -b
AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
; aux/cpuid -s
00060fb2 0f.6b.02
; 8.cpuid -n
On 13 Jan 2010, at 4:23 pm, Enrico Weigelt wrote:
* erik quanstrom quans...@quanstro.net wrote:
i think you misunderstand the problem. cookiefs' fs interface
is not the issue. cookiefs' robustness when storing the cookies
on the fileserver in the face of multiple concurrently running
On Jan 25, 2010, at 12:28 PM, Ethan Grammatikidis
eeke...@fastmail.fm wrote:
On 8 Jan 2010, at 7:12 am, Jeff Sickel wrote:
there's not a single searchable
site that provides a quick reference release that would give us
inroads
to all the /other/ operating systems available these
Tim Newsham wrote:
dns is a non-issue if the rest of ssl is working.
dns is irrelevant if it isn't.
Except when SSL has chinks in its armor. Like incidents of
certificate authorities being convinced to give out certs for
domains that don't belong to the requestor.
On Mon Jan 25 15:15:42 EST 2010, eeke...@fastmail.fm wrote:
On 13 Jan 2010, at 4:23 pm, Enrico Weigelt wrote:
* erik quanstrom quans...@quanstro.net wrote:
i think you misunderstand the problem. cookiefs' fs interface
is not the issue. cookiefs' robustness when storing the cookies
14 matches
Mail list logo
