Re: [9fans] extensions of "interest"
On Thu, 09 Apr 2009 17:10:47 MDT andrey mirtchovski wrote: > > Unfortunately we don't have exact analogs in s/w. We can > > only simplicate; we can't add lightness! > > but somehow we can add "weight". can't we? bash is perceivably > "heavier" than rc, xml perceivably "heavier" than 9p... statlite() > perceivably "heavier" than stat() :) Yes of course. But that is because they use a more complicated design that results in use of more code. What I meant is in a physical assembly you can carefully hollow out a solid part or use a lighter material to get a lighter part without changing its structural properties (much) and no other parts or couplings have to be changed. In a program one can use hand code asembly or inline code instead of calling a function, or call a function instead of RPC to a separate process and so on but in each case there is a tighter coupling that reduces flexibility. Design done by wizards have simpler and fewer parts -- they are simply much better at design. They "simplicate". But granted, the analogy is rather weak :-)
Re: [9fans] setting 9vx's sysname
> is there any particular reason 9vx doesn't set sysname to the host's > sysname if it can? is the current behavior depended upon anywhere? > > also, on my system, $terminal is set to "vx32 9vx" at boot, but i > can't find that declaration. what'm i missing? try main.c:/^init0. - erik
[9fans] setting 9vx's sysname
is there any particular reason 9vx doesn't set sysname to the host's sysname if it can? is the current behavior depended upon anywhere? also, on my system, $terminal is set to "vx32 9vx" at boot, but i can't find that declaration. what'm i missing?
Re: [9fans] extensions of "interest"
what, no SOAP? Not enterprise ready. On Thu, Apr 9, 2009 at 1:43 PM, andrey mirtchovski wrote: > i propose an extension to HTTP (call it HTTPeeLite) which allows me to > specify in my request to that webpage the format in which i prefer to > receive the man page. a 'setup' exchange can be sent beforehand to > establish the available types of documentation (.doc, .pdf, .tex, > .rtf, etc). > > -- And in the "Only Prolog programmers will find this funny" department: Q: How many Prolog programmers does it take to change a lightbulb? A: No. -- Ovid "By cosmic rule, as day yields night, so winter summer, war peace, plenty famine. All things change. Air penetrates the lump of myrrh, until the joining bodies die and rise again in smoke called incense." "Men do not know how that which is drawn in different directions harmonises with itself. The harmonious structure of the world depends upon opposite tension like that of the bow and the lyre." "This universe, which is the same for all, has not been made by any god or man, but it always has been, is, and will be an ever-living fire, kindling itself by regular measures and going out by regular measures" -- Heraclitus
Re: [9fans] a bit OT, programming style question
this is the "space-shuttle dichotomy." it's a false one. it's a continuum. its ends are dangerous. So somewhere in the middle is the golden mean? I have no objections to that. *BSD systems very well represent a silver, if not a golden, mean--just my idea, of course. it is interesting to me that some software manages to run off both ends of this continuum at the same time. in linux your termcap from 1981 will still work, but software written to access /sys last year is likely out-of-date. While I won't vouch for Linux as a good OS (user-land and kernel combined) I understand what you see as its eccentricity is merely a side-effect of openness. Tighten the development up and you get a BSD-style system (committer/contributor/maintainer/grunt/user highest-to-lowest ranking, with a demiurge position for Theo de Raadt). Tighten it even further up with in-ken shared among a core group of old-timers and thoroughbreds transmitted only to serious researchers and you get Plan 9. You are right, after all. It all lies on a continuum. Actually, more tightly regulated Linux distros such as Slackware readily demonstrate that; they easily beat all-out all-open distros like Fedora (whose existence is probably perceived at Red Hat as a big brainstorming project). your insinuation that *bsd is a real serious system and plan 9 is a research system doesn't make any historical sense to me. they both started as research systems. i am not aware of any law that prevents a system that started as a research project from becoming a serious production system. What I am insinuating is more like this: any serious system will sooner or later have to grow warts and/or contract herpes. That's an unavoidable consequence of social life. If you do insist that Plan 9 has no warts, or far less warts than the average, or that it has never seen a cold sore on its upper lip then I'll happily conclude it has never lived socially. And I haven't really ever used Plan 9 or "been into it." The no-herpes indicator is that strong. i know of many thousands of plan 9 systems in production right now. Good for you. Honestly. --On Thursday, April 09, 2009 11:06 AM -0400 erik quanstrom wrote: On Thu Apr 9 10:48:08 EDT 2009, eris.discor...@gmail.com wrote: Most of it in the 19 lines for one TERMCAP variable. Strictly a relic of the past kept with all good intentions: backward compatibility, and heeding [...] Quite a considerable portion of UNIX-like systems, FreeBSD in this case, is the way it is not because the developers are stupid, rather because they have a "constituency" to tend to. They aren't carefree researchers with high ambitions. this is the "space-shuttle dichotomy." it's a false one. it's a continuum. its ends are dangerous. on the one hand, if you change things, the new things are likely to be buggy. on the space shuttle, this is bad. people die. on the other hand, systems are not perfect. and if the problems are not addressed, eventually the system will need to much fixing and will be abandoned. yet bringing a new system on line is an even bigger risk. everything is new simultaneously. it is interesting to me that some software manages to run off both ends of this continuum at the same time. in linux your termcap from 1981 will still work, but software written to access /sys last year is likely out-of-date. your insinuation that *bsd is a real serious system and plan 9 is a research system doesn't make any historical sense to me. they both started as research systems. i am not aware of any law that prevents a system that started as a research project from becoming a serious production system. i know of many thousands of plan 9 systems in production right now. - erik
Re: [9fans] extensions of "interest"
On Fri, Apr 10, 2009 at 12:06 AM, Bakul Shah wrote: > Unfortunately we don't have exact analogs in s/w. We can > only simplicate; we can't add lightness! In manufacturing, I'd suppose lighter materials are harder to make and use, kind of like using low level languages for components. Standard optimization techique, replace measurably slow (heavy) components by something implemented closer (lighter) to the machine. Robby
Re: [9fans] extensions of "interest"
> Makes perfect sense for Chapman's purposes. Replace steel > with aluminium. Fiberglass instead of sheet metal and so on. > Unfortunately we don't have exact analogs in s/w. We can > only simplicate; we can't add lightness! read ken's code! - erik
Re: [9fans] a bit OT, programming style question
It only starts to balloon once you begin customizing bash. Have you customized your bash by aliases as long as tens or hundreds of lines? Now is it bash's fault you have defined an alias for something that ought to be a script/program in its own right? --On Thursday, April 09, 2009 3:34 PM -0400 "J.R. Mauro" wrote: No, it's very likely bigger. wc -l is lines of course, and I'm guessing each line is more than 1 character. However, $ set | wc -l 64 I don't quite get that locally. It only starts to balloon once you begin customizing bash. I'm not sure how rc handles functions, but the nice thing about zsh is that it compiles them to bytecode instead of this insanity that bash employs.
Re: [9fans] extensions of "interest"
> Unfortunately we don't have exact analogs in s/w. We can > only simplicate; we can't add lightness! but somehow we can add "weight". can't we? bash is perceivably "heavier" than rc, xml perceivably "heavier" than 9p... statlite() perceivably "heavier" than stat() :) we just don't quantify "weight" in terms of kilos, but we know it's there...
Re: [9fans] extensions of "interest"
On Thu, 09 Apr 2009 15:31:35 MDT andrey mirtchovski wrote: > ps, the quote is "Simplify, then add lightness" Makes perfect sense for Chapman's purposes. Replace steel with aluminium. Fiberglass instead of sheet metal and so on. Unfortunately we don't have exact analogs in s/w. We can only simplicate; we can't add lightness!
Re: [9fans] a bit OT, programming style question
Seems Charles Forsyth's bash (or wc -l) works very differently. [r...@host ~/]# set | wc -l 49 [r...@host ~/]# 37 out of 49 are just environment variables (as contrasted to shell variables). So the shell is using 12 variables in addition to the environment. A 'set | wc -c' gives 2133 over half of which are from the environment, 972 of them in TERMCAP. --On Thursday, April 09, 2009 3:28 PM -0400 "Devon H. O'Dell" wrote: 2009/4/9 Richard Miller <9f...@hamnavoe.com>: set | wc -l 8047 well. This is nearly as big as the shell itself in the (ahem) good old days. term% tar tzvf interdata_v6.tar.gz bin/sh --rwxr-xr-x 8316 Nov 13 15:48 1978 bin/sh No, it's very likely bigger. wc -l is lines of course, and I'm guessing each line is more than 1 character. However, $ set | wc -l 64 I don't quite get that locally. --dho
Re: [9fans] extensions of "interest"
> according to wikiquote.org it is "Simplicate, then add lightness". yes, it's even better than how i remember it!
Re: [9fans] a bit OT, programming style question
2009/4/9 Bakul Shah : > On Thu, 09 Apr 2009 15:28:58 EDT "Devon H. O'Dell" > wrote: >> $ set | wc -l >> 64 >> >> I don't quite get that locally. > > This must be on FreeBSD! > > % bash > $ echo $BASH_VERSION > 4.0.10(2)-release > $ set|wc > 72 1062107 It is actually CentOS 5 (work) with p9p. --dho
Re: [9fans] extensions of "interest"
> ps, the quote is "Simplify, then add lightness" > > On Thu, Apr 9, 2009 at 3:30 PM, andrey mirtchovski > wrote: >>> Is this sarcasm? >> >> yes, but not addressed towards Mr. Chapman, bless his cars. glad at >> least one person caught that. >> >> internet is bizarro world. >> according to wikiquote.org it is "Simplicate, then add lightness". i had not heard it before; it's good.
Re: [9fans] a bit OT, programming style question
> $ echo $BASH_VERSION
> 4.0.10(2)-release
> $ set|wc
> 72 1062107
if this is the criteria, plan 9 loses:
; printenv|wc
73 2102417
- erik
p.s.
; cat /bin/printenv
#!/bin/rc
rfork en
cd /env
for(i in *){
if(! test -s $i)
echo $i ^ '=()'
if not{
if(~ $i 'fn#'*) {
ifs='#' i = `{echo -n $i}
i = $i(2);
}
whatis $i
}
}
Re: [9fans] a bit OT, programming style question
> > I prefer the cadillac of shells (zsh) & the vw bug (rc). > I like this.
Re: [9fans] extensions of "interest"
ps, the quote is "Simplify, then add lightness" On Thu, Apr 9, 2009 at 3:30 PM, andrey mirtchovski wrote: >> Is this sarcasm? > > yes, but not addressed towards Mr. Chapman, bless his cars. glad at > least one person caught that. > > internet is bizarro world. >
Re: [9fans] extensions of "interest"
> Is this sarcasm? yes, but not addressed towards Mr. Chapman, bless his cars. glad at least one person caught that. internet is bizarro world.
Re: [9fans] a bit OT, programming style question
On Thu, 09 Apr 2009 15:28:58 EDT "Devon H. O'Dell" wrote: > $ set | wc -l > 64 > > I don't quite get that locally. This must be on FreeBSD! % bash $ echo $BASH_VERSION 4.0.10(2)-release $ set|wc 72 1062107 I prefer the cadillac of shells (zsh) & the vw bug (rc).
Re: [9fans] extensions of "interest"
> in the immortal words of Colin Chapman: "Complicate, then add weight". Is this sarcasm? I remember the quote as: "To add speed, add lightness" -Steve
Re: [9fans] a bit OT, programming style question
> No, it's very likely bigger. wc -l is lines of course Silly me, I was (optimistically) confusing it with wc -c.
Re: [9fans] extensions of "interest"
On Thu, Apr 09, 2009 at 03:22:48PM -0400, erik quanstrom wrote: > > > Already part of HTTP > > > > > > Accept: application/msword; q=1, application/pdf; > > > q=0.5,application/x-troff-ms; q=0.3 > > > > > > q is the level of preference, you'll get word docs first > > > > > > > > > > Wow. Could it get any worse? > > yes. just read a few lines further in the rfc and note that > there's also a "level" modifier. it's not clear to me what > level is supposed to do from their example. > >Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, > text/html;level=2;q=0.4, */*;q=0.5 and there is more! 10.3.1 300 Multiple Choices The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location. ... mjl
Re: [9fans] extensions of "interest"
On Thu, Apr 9, 2009 at 3:22 PM, erik quanstrom wrote: >> > Already part of HTTP >> > >> > Accept: application/msword; q=1, application/pdf; >> > q=0.5,application/x-troff-ms; q=0.3 >> > >> > q is the level of preference, you'll get word docs first >> > >> > >> >> Wow. Could it get any worse? > > yes. just read a few lines further in the rfc and note that > there's also a "level" modifier. it's not clear to me what > level is supposed to do from their example. > > Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, > text/html;level=2;q=0.4, */*;q=0.5 > I took a look at this page: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html And it seems to suggest that "level" is for picking between text/html and text/html [sic]
Re: [9fans] a bit OT, programming style question
> $ set | wc -l > 64 > > I don't quite get that locally. please upgrade your distribution. - erik
Re: [9fans] a bit OT, programming style question
> No, it's very likely bigger. wc -l is lines of course, and I'm > guessing each line is more than 1 character. However, > > $ set | wc -l > 64 > > I don't quite get that locally. It only starts to balloon once you begin customizing bash. I'm not sure how rc handles functions, but the nice thing about zsh is that it compiles them to bytecode instead of this insanity that bash employs.
Re: [9fans] extensions of "interest"
> > Already part of HTTP > > > > Accept: application/msword; q=1, application/pdf; > > q=0.5,application/x-troff-ms; q=0.3 > > > > q is the level of preference, you'll get word docs first > > > > > > Wow. Could it get any worse? yes. just read a few lines further in the rfc and note that there's also a "level" modifier. it's not clear to me what level is supposed to do from their example. Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5 - erik
Re: [9fans] a bit OT, programming style question
2009/4/9 Richard Miller <9f...@hamnavoe.com>: >> set | wc -l >> 8047 >> well. > > This is nearly as big as the shell itself in the (ahem) good old days. > > term% tar tzvf interdata_v6.tar.gz bin/sh > --rwxr-xr-x 8316 Nov 13 15:48 1978 bin/sh No, it's very likely bigger. wc -l is lines of course, and I'm guessing each line is more than 1 character. However, $ set | wc -l 64 I don't quite get that locally. --dho
Re: [9fans] extensions of "interest"
On Thu, Apr 9, 2009 at 3:05 PM, maht wrote: > andrey mirtchovski wrote: >> >> i propose an extension to HTTP (call it HTTPeeLite) which allows me to >> specify in my request to that webpage the format in which i prefer to >> receive the man page. a 'setup' exchange can be sent beforehand to >> establish the available types of documentation (.doc, .pdf, .tex, >> .rtf, etc). >> >> >> > > Already part of HTTP > > Accept: application/msword; q=1, application/pdf; > q=0.5,application/x-troff-ms; q=0.3 > > q is the level of preference, you'll get word docs first > > Wow. Could it get any worse?
Re: [9fans] extensions of "interest"
andrey mirtchovski wrote: i propose an extension to HTTP (call it HTTPeeLite) which allows me to specify in my request to that webpage the format in which i prefer to receive the man page. a 'setup' exchange can be sent beforehand to establish the available types of documentation (.doc, .pdf, .tex, .rtf, etc). Already part of HTTP Accept: application/msword; q=1, application/pdf; q=0.5,application/x-troff-ms; q=0.3 q is the level of preference, you'll get word docs first
Re: [9fans] #! scripts
> See exec(2): > For a file beginning #!, the arguments passed to the program > (/bin/rc in the example above) will be the name of the file > being executed, any arguments on the #! line, the name of > the file again, and finally the second and subsequent argu- > ments given to the original exec call. The result honors > the two conventions of a program accepting as argument a > file to be interpreted and argv[0] naming the file being > executed. I always seem to expect a subtly different behaviour from what I get. In this case, I note now that NetBSD behaves exactly the same, but I only considered trying it out after you've made me read that passage for the sixteenth time. I guess I always read in it what I was hoping to find. I guess that means I have nothing to fix. Not only, but any extensions I was hoping for are shown to be utterly impractical :-( Let me go back to ELF... ++L
Re: [9fans] #! scripts
See exec(2): For a file beginning #!, the arguments passed to the program (/bin/rc in the example above) will be the name of the file being executed, any arguments on the #! line, the name of the file again, and finally the second and subsequent argu- ments given to the original exec call. The result honors the two conventions of a program accepting as argument a file to be interpreted and argv[0] naming the file being executed.
[9fans] #! scripts
I'm messing around with /sys/src/9/port/sysproc.c and I may have distorted it beyond recovery, but I have a feeling this problem isn't of my own making. I have: ; cat /bin/ll #!/bin/ls -l ; If I invoke ll ; ll --rwxrwxr-x M 9 lucio lucio 13 Jan 31 09:30 /bin/ll ; no matter where I invoke it, not what I expect at all. I also have (my prompt is actually "term% ", in case it matters): ; cat /bin/en #!/bin/echo -n ; en /bin/en; Now, the question that makes this all very strange is: how does /rc/bin/service/tcp17010 which contains: #!/bin/cpu -R actually manage to work? I have broken it during the course of today, but using 9pccpu.gz off sources as I did now for confirmation, it seems to work. In summary, I think sysproc.c:/^sysexec is doing something wrong with the script header line. It is rather confusing code and I'm sure it was more robust last time I messed with it, probably over a year ago. I plan to fix it, but I need to understand what's broken first, and that bit I'm finding hard to do. Could someone with a stable version of Plan 9 please confirm that it isn't my mind that has suddenly slipped? ++L PS: invoking ; ll . may give an clearer view of the nature of the problem.
Re: [9fans] a bit OT, programming style question
> set | wc -l > 8047 > well. This is nearly as big as the shell itself in the (ahem) good old days. term% tar tzvf interdata_v6.tar.gz bin/sh --rwxr-xr-x 8316 Nov 13 15:48 1978 bin/sh
Re: [9fans] extensions of "interest"
from the man pages^W^Wpdf: // FUTURE DIRECTIONS // // None. we should be so lucky.
Re: [9fans] extensions of "interest"
On Thu, Apr 9, 2009 at 1:48 PM, erik quanstrom wrote: > On Thu Apr 9 13:44:50 EDT 2009, mirtchov...@gmail.com wrote: >> i propose an extension to HTTP (call it HTTPeeLite) which allows me to >> specify in my request to that webpage the format in which i prefer to >> receive the man page. a 'setup' exchange can be sent beforehand to >> establish the available types of documentation (.doc, .pdf, .tex, >> .rtf, etc). > > or you could refrain from making the web any worse by just > providing the document in ... oh, what's that archane format ... > right, html. if i recall correctly, it's the standard for web content. > > ☺ > > by the way, this is an absolute gem from sutoc > > "handles are not inherently portable. however, between like > architechtures and software operating system support versions > things just might work out. > > fills me with optimism. Almost as cheery as alloca() and gets(), another fine pair of functions we should all use more often :) > > - erik > >
Re: [9fans] extensions of "interest"
> or you could refrain from making the web any worse by just > providing the document in ... oh, what's that archane format ... > right, html. if i recall correctly, it's the standard for web content. in the immortal words of Colin Chapman: "Complicate, then add weight".
Re: [9fans] a bit OT, programming style question
set | wc -l 8047 well. certainly if you leave bash or even dash set as the shell, a terminal or 9term window takes ages on ubuntu. set the shell to p9p rc, 9term starts straight away and you're a better person for it.
Re: [9fans] extensions of "interest"
> On Thu, Apr 9, 2009 at 1:25 PM, erik quanstrom wrote: > > On Thu Apr 9 13:19:11 EDT 2009, rminn...@gmail.com wrote: > >> www.pdl.cmu.edu/posix > >> > >> statlite() > > > > the statlite man page is itself lightweight, being available > > on the web in pdf form. > > And MS doc! There's a common Unix-y file format. although statlite seems impossible to use, it's by no means the most troublesome syscall suggested. check out openg and sutoc. kernel file handles? by the way, it's a long time since i've seen a precidence bug in a man page, but openg manages. see p. 7 of openg linked from the same page. - erik
Re: [9fans] extensions of "interest"
On Thu Apr 9 13:44:50 EDT 2009, mirtchov...@gmail.com wrote: > i propose an extension to HTTP (call it HTTPeeLite) which allows me to > specify in my request to that webpage the format in which i prefer to > receive the man page. a 'setup' exchange can be sent beforehand to > establish the available types of documentation (.doc, .pdf, .tex, > .rtf, etc). or you could refrain from making the web any worse by just providing the document in ... oh, what's that archane format ... right, html. if i recall correctly, it's the standard for web content. ☺ by the way, this is an absolute gem from sutoc "handles are not inherently portable. however, between like architechtures and software operating system support versions things just might work out. fills me with optimism. - erik
Re: [9fans] extensions of "interest"
i propose an extension to HTTP (call it HTTPeeLite) which allows me to specify in my request to that webpage the format in which i prefer to receive the man page. a 'setup' exchange can be sent beforehand to establish the available types of documentation (.doc, .pdf, .tex, .rtf, etc).
Re: [9fans] extensions of "interest"
On Thu, Apr 9, 2009 at 1:25 PM, erik quanstrom wrote: > On Thu Apr 9 13:19:11 EDT 2009, rminn...@gmail.com wrote: >> www.pdl.cmu.edu/posix >> >> statlite() > > the statlite man page is itself lightweight, being available > on the web in pdf form. And MS doc! There's a common Unix-y file format. > > - erik > >
Re: [9fans] a bit OT, programming style question
On Thu, Apr 9, 2009 at 9:44 AM, Eris Discordia wrote: >> Try env | wc -l in bash. Now tell me why that value is so big. > >> [r...@host ~]# env | wc -l >> 37 >> [r...@host ~]# > > Is that very high? I don't even know if it is or how it would mean anything > bad (or good for that matter) assuming it were high. Not to mention, it's a > very bad metric. Because: > >> [r...@host ~]# env | wc -c >> 1404 >> [r...@host ~]# > > Most of it in the 19 lines for one TERMCAP variable. Strictly a relic of the > past kept with all good intentions: backward compatibility, and heeding the > diversity of hardware and configuration that still exists out there. 5 of > the other 18 lines are completely specific to my installation. That leaves > us with 13 short lines. Grumble... s/env/set And then you see the guts of bash spill out. > > Quite a considerable portion of UNIX-like systems, FreeBSD in this case, is > the way it is not because the developers are stupid, rather because they > have a "constituency" to tend to. They aren't carefree researchers with high > ambitions. I leveled no claims against *BSD or Linux. I'm simply trying to point out that bash is utter garbage, as its own man page indicates. > > --On Tuesday, April 07, 2009 11:04 PM -0400 "J.R. Mauro" > wrote: > >> On Tue, Apr 7, 2009 at 9:48 PM, Eris Discordia >> wrote: The man page *does* say it's too big and slow. So does the bash manpage. And getting readline to do anything sane is about as fun as screwing around with a terminfo file. >>> >>> A bad implementation is not a bad design. And, in fact, the badness of >>> the implementation is even questionable in the light of bash's normal >>> behavior or the working .inputrc files I've been using for some time. >> >> Behavior is not indicative of good design. It just means that the >> bandaids heaped upon bash (and X11, and...) make it work acceptably. >> >> Try env | wc -l in bash. Now tell me why that value is so big. >> >>> >>> Anyway, thanks for the info. >>> >>> --On Tuesday, April 07, 2009 3:57 PM -0400 "J.R. Mauro" >>> wrote: >>> On Tue, Apr 7, 2009 at 2:21 PM, Eris Discordia wrote: > > I see. But seriously, readline does handle bindings and line editing > for bash. Except it's a function instead of a program and you think > it's a bad idea. The man page *does* say it's too big and slow. So does the bash manpage. And getting readline to do anything sane is about as fun as screwing around with a terminfo file. > > --On Tuesday, April 07, 2009 10:31 PM +0800 sqweek > wrote: > >> 2009/4/7 Eris Discordia : > > Keyboard > bindings for example; why couldn't they be handled by a program > that just does keyboard bindings + line editing, and writes > finalized lines to the shell. >>> >>> Like... readline(3)? >> >> No. >> -sqweek >> > > > > --On Tuesday, April 07, 2009 8:09 AM -0700 ron minnich > wrote: > >> On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia >> wrote: >> >>> >>> Like... readline(3)? >> >> one hopes not. >> >> ron >> > > > > > > >>> >>> >>> >>> >>> >>> >> > >
Re: [9fans] extensions of "interest"
On Thu Apr 9 13:19:11 EDT 2009, rminn...@gmail.com wrote: > www.pdl.cmu.edu/posix > > statlite() the statlite man page is itself lightweight, being available on the web in pdf form. - erik
[9fans] extensions of "interest"
www.pdl.cmu.edu/posix statlite() ron
Re: [9fans] a bit OT, programming style question
On Thu Apr 9 10:48:08 EDT 2009, eris.discor...@gmail.com wrote: > Most of it in the 19 lines for one TERMCAP variable. Strictly a relic of > the past kept with all good intentions: backward compatibility, and heeding [...] > Quite a considerable portion of UNIX-like systems, FreeBSD in this case, is > the way it is not because the developers are stupid, rather because they > have a "constituency" to tend to. They aren't carefree researchers with > high ambitions. this is the "space-shuttle dichotomy." it's a false one. it's a continuum. its ends are dangerous. on the one hand, if you change things, the new things are likely to be buggy. on the space shuttle, this is bad. people die. on the other hand, systems are not perfect. and if the problems are not addressed, eventually the system will need to much fixing and will be abandoned. yet bringing a new system on line is an even bigger risk. everything is new simultaneously. it is interesting to me that some software manages to run off both ends of this continuum at the same time. in linux your termcap from 1981 will still work, but software written to access /sys last year is likely out-of-date. your insinuation that *bsd is a real serious system and plan 9 is a research system doesn't make any historical sense to me. they both started as research systems. i am not aware of any law that prevents a system that started as a research project from becoming a serious production system. i know of many thousands of plan 9 systems in production right now. - erik
Re: [9fans] a bit OT, programming style question
Try env | wc -l in bash. Now tell me why that value is so big. [r...@host ~]# env | wc -l 37 [r...@host ~]# Is that very high? I don't even know if it is or how it would mean anything bad (or good for that matter) assuming it were high. Not to mention, it's a very bad metric. Because: [r...@host ~]# env | wc -c 1404 [r...@host ~]# Most of it in the 19 lines for one TERMCAP variable. Strictly a relic of the past kept with all good intentions: backward compatibility, and heeding the diversity of hardware and configuration that still exists out there. 5 of the other 18 lines are completely specific to my installation. That leaves us with 13 short lines. Quite a considerable portion of UNIX-like systems, FreeBSD in this case, is the way it is not because the developers are stupid, rather because they have a "constituency" to tend to. They aren't carefree researchers with high ambitions. --On Tuesday, April 07, 2009 11:04 PM -0400 "J.R. Mauro" wrote: On Tue, Apr 7, 2009 at 9:48 PM, Eris Discordia wrote: The man page *does* say it's too big and slow. So does the bash manpage. And getting readline to do anything sane is about as fun as screwing around with a terminfo file. A bad implementation is not a bad design. And, in fact, the badness of the implementation is even questionable in the light of bash's normal behavior or the working .inputrc files I've been using for some time. Behavior is not indicative of good design. It just means that the bandaids heaped upon bash (and X11, and...) make it work acceptably. Try env | wc -l in bash. Now tell me why that value is so big. Anyway, thanks for the info. --On Tuesday, April 07, 2009 3:57 PM -0400 "J.R. Mauro" wrote: On Tue, Apr 7, 2009 at 2:21 PM, Eris Discordia wrote: I see. But seriously, readline does handle bindings and line editing for bash. Except it's a function instead of a program and you think it's a bad idea. The man page *does* say it's too big and slow. So does the bash manpage. And getting readline to do anything sane is about as fun as screwing around with a terminfo file. --On Tuesday, April 07, 2009 10:31 PM +0800 sqweek wrote: 2009/4/7 Eris Discordia : Keyboard bindings for example; why couldn't they be handled by a program that just does keyboard bindings + line editing, and writes finalized lines to the shell. Like... readline(3)? No. -sqweek --On Tuesday, April 07, 2009 8:09 AM -0700 ron minnich wrote: On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia wrote: Like... readline(3)? one hopes not. ron
Re: [9fans] Is this Plan9 performance, Ok
On Thu Apr 9 05:18:31 EDT 2009, bdhee...@gmail.com wrote: > Extraction of only a 180M archive knelled down a 1.8Ghz/P-M4/i686/1Gb > RAM/40GiB IDE HDD machine running vanilla Plan9 installed natively: > > term% cat /dev/sdC0/ctl |grep dma > config 0040 capabilities 2F00 dma 00550020 dmactl 00550020 rwm 8 rwmctl 0 > term% time /n/mon/mnt/sda9/Downloads/Plan9/mroot-linuxemu.tbz2 > ... > 183.27u 31.06s 623.86r tar zxf > /n/mon/mnt/sda9/Downloads/Plan9/mroot-linuxemu.tbz2 > term% ls -l /n/mon/mnt/sda9/Downloads/Plan9/mroot-linuxemu.tbz2 > --rw-rw-r-- M 47 root wheel 188569960 Apr 8 16:15 a laptop drive of that general description is probablly good for 20mb/s sequential io. assuming that the uncompressed archive is 3x larger, you're getting about 1mb/s writes even with the slow decompression. it looks like that archive is pulled over the network. since you have a 3c905, that would be at a maximum of about 10mb/s. if you're linked at 10mb/s, the limit is about 1mb/s. i'd recommend checking the drive's speed with dd. time dd -if /dev/sdC0/data -of /dev/null -count 5000 -bs 64k i don't recall if the 3c905 will tell you its link speed. you can try /dev/kmesg or /net/ether0/ifstats under mbps. the latter may be the maximum mbps the card is capable of, due to the fact mbps is used to size queues. i like the suggestion to time pulling down the archive and sending it to /dev/null. since you have enough memory. you could seperately time extracting it to ramfs. > Moreover, it is strange that Plan9 running under QEMU on 2.4Ghz/Core2 > Duo/2Gb RAM/250GiB SATA/IDE HDD machine out performs a natively > installed one. what is slower, exactly? - erik
Re: [9fans] Is this Plan9 performance, Ok
/n/mon/mnt/sda9/Downloads/Plan9/mroot-linuxemu.tbz2 how is that mounted ? you've got two issues, how the tbz2 get to plan9 and then how long it takes to unzip try % cd % time cp /n/mon/mnt/sda9/Downloads/Plan9/mroot-linuxemu.tbz2 . % time zxf mroot-linuxemu.tbz2 so we know what it is you're timing
[9fans] Is this Plan9 performance, Ok
Extraction of only a 180M archive knelled down a 1.8Ghz/P-M4/i686/1Gb RAM/40GiB IDE HDD machine running vanilla Plan9 installed natively: term% cat /dev/sdC0/ctl |grep dma config 0040 capabilities 2F00 dma 00550020 dmactl 00550020 rwm 8 rwmctl 0 term% time /n/mon/mnt/sda9/Downloads/Plan9/mroot-linuxemu.tbz2 ... 183.27u 31.06s 623.86r tar zxf /n/mon/mnt/sda9/Downloads/Plan9/mroot-linuxemu.tbz2 term% ls -l /n/mon/mnt/sda9/Downloads/Plan9/mroot-linuxemu.tbz2 --rw-rw-r-- M 47 root wheel 188569960 Apr 8 16:15 /n/mon/mnt/sda9/Downloads/Plan9/mroot-archlinux.tar.bz2 term% pci -v 0.0.0: brg 06.00.00 8086/1a30 0 Intel Corporation 82845G[GL/GV/GE/PE] Host-Hub Interface Bridge 0.1.0: brg 06.04.00 8086/1a31 0 Intel Corporation 82845[MP/MZ] AGP Bridge 0.29.0: usb 0c.03.00 8086/2482 11 4:bf81 32 Intel Corporation 82801CA/CAM USB Controller 0.30.0: brg 06.04.00 8086/2448 0 Intel Corporation 82801BAM/CAM/DBM Hub Interface to PCI Bridge 0.31.0: brg 06.01.00 8086/248c 0 Intel Corporation 82801CAM LPC Interface or ISA bridge: see Notes 0.31.1: disk 01.01.8a 8086/248a 11 0:01f1 16 1:03f5 16 2:0171 16 3:0375 16 4:bfa1 16 5: 1024 Intel Corporation 82801CAM UltraATA IDE Controller 0.31.5: aud 04.01.00 8086/2485 11 0:d801 256 1:dc81 64 Intel Corporation 82801CA/CAM AC97 Audio Controller 0.31.6: ser 07.03.00 8086/2486 11 0:d401 256 1:dc01 128 Intel Corporation 82801CA/CAM AC 97 Modem Controller 1.0.0: vid 03.00.00 1002/4c57 11 0:e008 134217728 1:c001 256 2:fcff 65536 ATI Technologies Inc. fdds Radeon Mobility M7 LW 2.0.0: net 02.00.00 10b7/9200 11 0:ec81 128 1:f8fffc00 128 3Com Corporation 3C905 CX-TX-M Fast EtherLink for PC Management NIC 2.1.0: brg 06.07.00 104c/ac51 11 Texas Instruments PCI-1420 Texas Instruments 1420 2.1.1: brg 06.07.00 104c/ac51 11 Texas Instruments PCI-1420 Texas Instruments 1420 2.3.0: net 02.00.00 168c/001b 11 0:f8fe 65536 Atheros Communications Inc. AR5006X 802.11abg NIC Moreover, it is strange that Plan9 running under QEMU on 2.4Ghz/Core2 Duo/2Gb RAM/250GiB SATA/IDE HDD machine out performs a natively installed one. -- Dr Balwinder S "bsd" Dheeman Registered Linux User: #229709 Anu'z li...@home (Unix Shoppe)Machines: #168573, 170593, 259192 Chandigarh, UT, 160062, India Plan9, T2, Arch/Debian/FreeBSD/XP Home: http://cto.homelinux.net/~bsd/ Visit: http://counter.li.org/
