Re: [9fans] arch specific executables
i have a little program, aux/cpuid perhaps this would be better in /dev/cons/cpuid ? just my 2ยข -Steve
Re: [9fans] arch specific executables
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 cmpswap486 i8253set on
Re: [9fans] partial cp
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
Re: [9fans] Shall we fix the use of Up/Dn arrows?
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 with very unpleasant consqeuences. This is the 1st time I hear about such a misfortune... :) I've done the same, and it was something scary like rm -rf * When people complain in irc has no history I say if you need to re-do commands, use a script and /dev/text is your friend if you are half way through. The Scout Motto is: BE PREPARED which means you are always in a state of readiness in mind and body to do your DUTY. * Be Prepared in Mind by having disciplined yourself to be obedient to every order, and also by having thought out beforehand any accident or situation that might occur, so that you know the right thing to do at the right moment, and are willing to do it. * Be Prepared in Body by making yourself strong and active and able to do the right thing at the right moment, and do it. To do the right thing at the right moment can be extreme: Where a man has gone so far as to attempt suicide, a Scout should know what to do with him. BE PREPARED to die for your country if need be, so that when the moment arrives you may charge home with confidence, not caring whether you are going to be killed or not Not sure how the concept of a line delimited by newlines relates to moving the cursor up one physical line on the screen. Working out where to move the cursor to
Re: [9fans] arch specific executables
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.
Re: [9fans] arch specific executables
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 hack i currently have is objtype=386 as the first line of the mkfile. Why not make it build everywhere and have it print a diagnostic for platforms it doesn't support. E.g. x86 assembly doesn't often assemble with an arm assembler. :-) - erik
Re: [9fans] arch specific executables
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 what i was looking for. i needed the cpuid family, model, and stepping info. it's not available in '#P' and i didn't want to reboot. also, the vendor string is helpful and seems silly to add to the kernel. ; 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 0x8005 # cache sizes ff08ff08 ff20ff20 40020140 40020140 - erik
Re: [9fans] p9p funny
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 likely to see it when using non-p9p tools and setting cooked mode from the menu. Using p9p tools via ssh also seems to trigger it. (i.e. open 9term, ssh to another machine, and run 9 rc.) I actually thought it was a feature of cooked mode, I was quite surprised to see it not manifest when I tested just now.
Re: [9fans] arch specific executables
x86 assembly doesn't often assemble with an arm assembler. :-) Oh come on. Everything you need to make this work is already there.
Re: [9fans] arch specific executables
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 0x8005 # cache sizes ff08ff08 ff20ff20 40020140 40020140 All of this stuff is available via cpuid, including the string. I think the kernel device is the logical place to put it. Maybe I'm misunderstanding however. that's what i did. from user mode. there are no magic strings in the executable. see contrib quanstro/cpuid. no man page. no time today. - erik
Re: [9fans] Design of webfs and webcookies
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 cookiefs' is. ah, you're talking about the situation when multiple cookiefs instances running on the same storage ? hmm, that's the classical multi-access problem ;-O but how do you get into that situation in the first place ? (more to the point: who starts these multiple instances ?) Wouldn't multiple instances of cookiefs neatly provide transaction isolation?
Re: [9fans] vms
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 days. Not sure if I understood what you mean but if I did, you want this: http://wiki.osdev.org/Main_Page Particularly this page: http://wiki.osdev.org/Projects Forums would be worth searching too, but as to a nice organized list, good luck finding someone to maintain that. Also this: http://www.dmoz.org/Computers/Software/Operating_Systems/ -- Ethan Grammatikidis
Re: [9fans] Are we ready for DNSSEC ?
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. http://instigations.com/fudili/certsetc.html (scroll down)
Re: [9fans] Design of webfs and webcookies
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 on the fileserver in the face of multiple concurrently running cookiefs' is. ah, you're talking about the situation when multiple cookiefs instances running on the same storage ? hmm, that's the classical multi-access problem ;-O but how do you get into that situation in the first place ? (more to the point: who starts these multiple instances ?) Wouldn't multiple instances of cookiefs neatly provide transaction isolation? i don't see how you could get acid semantics without locking the cookie file for the duration of each http exchange. this is because one can't predict the returned cookies or abort the request and try again. sending the same http request twice might end up charging your credit card twice. i'm not sure this level of inconsistency matters. - erik
