Conversation with #inferno at Wed Aug 19 12:01:54 2009 on powerman-asdf@irc.freenode.net (irc)
(12:51:30) maht_ left the room (quit: Remote closed the connection).
(12:52:31) maht [n=maht__@85.189.31.174.proweb.managedbroadband.co.uk] entered the room.
(13:33:19) sqweek [n=none@124-169-155-176.dyn.iinet.net.au] entered the room.
(14:59:57) j123m [n=j1m@unas-revda.interra.ru] entered the room.
(16:09:41) robot12 left the room (quit: "Ухожу я от вас (xchat 2.4.5 или старше)").
(16:44:04) underspecified left the room (quit: ).
(17:03:20) xjrn left the room (quit: Read error: 60 (Operation timed out)).
(17:17:43) mjl-: does anyone have code for writing cgi programs from the inferno shell?
(17:18:02) mjl-: first thing i want is to parse the query string
(17:18:21) mjl-: and i guess some functions to lookup keys
(17:21:37) uriel: mjl-: I think kris built some inferno shell extension to do scgi 
(17:21:50) uriel: but I'm not sure how it worked, maybe you should send him an email asking
(17:24:09) mjl-: i remember him doing some scgi things
(17:24:12) mjl-: i'll have a look
(17:24:37) anothy_x: can anyone point me at a description (really, a comparison) of the various *cgi* (pseudo-)standards?
(17:25:38) mjl-: not me really :)
(17:25:43) mjl-: i can find the scgi "spec"
(17:25:59) mjl-: http://www.python.ca/scgi/protocol.txt
(17:26:35) anothy_x: i have some limbo code which claims to do "cgi", but i'm not sure if that's "real" cgi, and don't really know how to verify it. i didn't write the code.
(17:28:00) mjl-: "real cgi" would be when it was launched by a httpd, having client POST data as stdin (or no stdin for GET/HEAD), and writing a "status: 200" header (or failure header) to stdout, following by more headers (eg content-type), followed by one empty line followed by the message body
(17:28:08) mjl-: and it would look at QUERY_STRING for get parameters
(17:28:26) mjl-: the environment variable QUERY_STRING that is, which would have been set by the httpd before launching the cgi program
(17:28:41) mjl-: and perhaps REQUEST_METHOD (for GET/POST/HEAD)
(17:28:51) mjl-: and a bunch of others
(17:30:23) mjl-: with scgi, the httpd will (tcp-)connect to an scgid for each httpd request.  the scgid will then spawn the program with the tcp's fd as the programs stdin/stdout.  the httpd starts out by sending a simple message to pass the environment(request) variables to the scgid.
(17:30:53) anothy_x: i'm quite certain this code isn't doing scgi.
(17:31:24) anothy_x: it likely predates scgi's existence.
(17:31:52) mjl-: probably.  scgi isn't used all that much afaik (but i don't know why)
(17:32:03) mjl-: fastcgi is another thing but seems way overengineered
(17:32:07) anothy_x: requires an additional moving part.
(17:32:12) mjl-: true
(17:32:23) mjl-: but fastcgi seems to be more popular, and is a bigger moving part...
(17:35:25) anothy_x: first-mover advantage.
(17:35:50) anothy_x: in my experience, either in-server cgi or things like mod_whatever are still dominant.
(17:35:57) maht: its because fasecgi connections are persistent
(17:36:03) maht: fastcgi
(17:36:15) mjl-: maht: that sounds like a disadvantage to me, not an advantage
(17:36:53) maht: pros & cons, means keeping db connections open and the like
(17:36:57) mjl-: it needs to reinvent message boundary indications.  which tcp gives for free
(17:37:22) mjl-: ah like that
(17:37:23) maht: it makes a new tcp conneciton every time
(17:37:32) maht: (or can do)
(17:37:38) mjl-: well, scgi can do the same
(17:37:50) maht: I wrote a fsatcgi for limbo I think, certainyl for plan9
(17:37:52) mjl-: noone said the scgid has to actually create a new process for each request
(17:38:28) mjl-: i wonder if db creation is actually slow.  that's on unix just opening a unix pipe or tcp connection isn't it?
(17:38:40) mjl-: perhaps that causes a full/slow fork or something
(17:38:45) mjl-: ah well!
(17:39:11) maht: they set up lots of memory
(17:39:21) mjl-: anothy_x: mod_* is popular yeah.  something monoculture design (although i think there is at least one other httpd beside apacheds that also does this mod_* stuff)
(17:39:36) maht: lighttpd
(17:39:45) maht: & IIS :>
(17:39:50) mjl-: maht: but the db can just have some worker procs etc, and not do anything heavy per connection
(17:40:07) mjl-: at least two already then :)
(17:40:09) maht: yeah, php uses that method
(17:40:28) maht: hundreds of solutions to the same problem
(17:44:21) underspecified [n=eric@softbank220043052007.bbtec.net] entered the room.
(17:45:45) anothy_x: speaking of hundreds of solutions to the same problem:
(17:45:54) anothy_x: recommendations on how to package and distribute inferno software?
(17:46:38) anothy_x: i'm currently thinking mkfs archives. unpackable by multiple systems, easy to generate from a proto file.
(17:48:03) maht: unzip & tar are available & tarfs
(17:48:29) mjl-: tar seems easiest to me.  is mkfs extractable on eg unix?
(17:48:42) maht: but I've puzzled for years how best to do it
(17:48:49) mjl-: (you'll probably have inferno around, but still)
(17:48:50) maht: /usr/$user/appl
(17:49:11) maht: but then you have ot have /usr/$user/module
(17:49:19) anothy_x: there's mkext for each platform that supports inferno.
(17:49:20) maht: and your paths go all screwey
(17:49:20) mjl-: i'm still making each piece a software an inferno tree with appl/cmd, module and man/ etc.
(17:49:57) maht: yeah thats the way i guess, just let the user decide
(17:50:00) mjl-: maht: it works if you put module/ first in the roots mkfile and demand a "mk install", so the module/*.m files get installed in inferno's /module before other code is built
(17:50:53) maht: which is ok until thats not writable
(17:51:01) anothy_x: hrm. but that fits poorly with the rest of the system.
(17:51:02) mjl-: true
(17:51:12) anothy_x: have /appl/cmd/mypackage/man? ew.
(17:51:33) mjl-: anothy_x: no, just /usr/mjl/code/somepackage/^(man module appl/cmd appl/lib) etc
(17:52:01) anothy_x: oh, i see. right, that's like what i was thinking.
(17:52:11) maht: then you have the problem of load Module->PATH
(17:52:14) mjl-: anothy_x: examples here: http://www.ueber.net/code/
(17:52:15) anothy_x: i want a package that can be extracted over root and fit well, if that's what the user wants.
(17:52:37) mjl-: anothy_x: well... you'll still need the .dis files mentioned in the mkfiles...
(17:52:38) anothy_x: maht: yeah, but that's just changing the .m. it'll get picked up at load time.
(17:52:48) maht: I've asked on the ML a few times but no-one has even engaged with it, let along worked something out
(17:54:15) anothy_x: on unix, i like /opt-style packages best, by far. simple to make, simple to use, clear to inspect.
(17:54:45) ***uriel hates /opt
(17:54:50) anothy_x: but we don't have any history of anything like that in plan9 or inferno.
(17:54:55) uriel: /usr/local/ sucks enough
(17:55:14) anothy_x: opt is worlds better than /usr/local. /usr/local just becomes a horrid mess very, very quickly.
(17:55:15) uriel:  /opt is just bizarre, only non-standard stuff seems to use it
(17:55:28) anothy_x: /opt is an older, SysV-era standard.
(17:56:01) anothy_x: modern /opt-style packages are sort of a degenerate form (dropping some of they SysV indexing stuff that nobody except SysV and Sun ever implemented)
(17:56:07) uriel: sure, /usr/local/ is a mess, but again /opt seems to be only for random stuff nobody in their right mind uses (I seem to remember open office installing itself there, and perhaps vmware?)
(17:56:08) anothy_x: what don't you like about it?
(17:56:32) anothy_x: holding which packages use it against the structure is silly.
(17:56:46) uriel: well, I guess it is not so much 'it' as all the packages I have seen that install themselves there used to be the worst of the worst
(17:57:26) uriel: and there is no reason why packages can't put something sane under /usr/local/
(17:57:33) anothy_x: maybe, but that's totally independent of the comparative qualities of the model.
(17:57:47) mjl-: the /opt was at some point used quite a bit for commercial software
(17:57:48) anothy_x: well, except /usr/local is intended (by convention) to be, essentially, a mirror of /.
(17:57:59) uriel: well, /opt as far as I could see didn't seem to provide much of a model, at least not any model anyone I have seen follows
(17:58:07) maht:  /apps/$appname/{bin, man .... }
(17:58:18) maht: oh and /app/$appname/run
(17:58:23) anothy_x: people have started using /opt as a shorter synonym for /usr/local, but that's modern linux brain damage.
(17:58:27) uriel: mjl-: exactly, all of which was abominable
(17:58:28) mjl-: but its either:  1. install things into a global directory (eg /dis/opt/) and make a mess.  2. install each package into a separate dir, and do lots of binds
(17:58:31) maht: but thats apps, cmdline tools are a different beast
(17:58:37) anothy_x: the traditional model is /opt/packagename.
(17:59:18) ***uriel still sees little difference between /opt and /usr/local/, other than the kinds of packages that tend to use one of the other.. 
(17:59:52) uriel: oh, Oracle would dump itself into /opt/ *yuck*
(17:59:57) anothy_x: uriel: traditionally you had /usr/local/bin, /usr/local/man, /usr/local/lib, &c. with everything just dumped in there.
(18:00:14) anothy_x: but /opt/packagename/bin, /opt/packagename/man, &c.
(18:00:15) uriel: anothy_x: yes, i know, it still happens, and yea, I agree it sucks
(18:00:28) anothy_x: makes it much easier to see what's installed, find the right bits, and only include what you want.
(18:00:34) anothy_x: (not to mention make a clean uninstall)
(18:00:37) uriel: anothy_x: in practice in my experience /opt/foo/* is a huge fucking mess that has no semblance to /
(18:00:42) uriel: (or to anything remotely sane)
(18:01:15) uriel: I agree that keeping each package in one place does makes sense
(18:01:26) mjl-: so far i like the system netbsd uses, with base system in normal /usr/bin etc dirs, and packages all in one /usr/pkg/bin and other /usr/pkg dirs.  better than on linux, where lots of non-base (there is no "base" really) ends up in /usr/bin and friends.
(18:01:44) uriel: and it is a nice thing to have, but you can have that just as much in /usr/local/ if your software is designed to do so
(18:01:49) mjl-: i don't like one dir per packages, because you'll end up with a huge PATH or huge number of binds
(18:01:56) anothy_x: is that a literal "pkg", or is that a dir per package?
(18:02:01) mjl-: anothy_x: literal
(18:02:11) anothy_x: mjl-: yeah, but what's the cost of that (large path or binds)?
(18:02:25) mjl-: anothy_x: ugliness
(18:02:30) mjl-: how do you generate the list of binds you need?
(18:02:38) uriel: well, I hate long paths, I don't mind lots of binds
(18:02:46) uriel: but lunix being lunix, you are stuck with paths
(18:02:53) mjl-: if you make a new namespace and want to run any programs, how will you fix the namespace?
(18:03:19) mjl-: run a full shell script to set up the namespace i guess...
(18:03:31) uriel: mjl-: seem simple enough to me
(18:03:49) anothy_x: mjl-: it's a good question. i'd provide a "readme"-ish thing with the list of things to stick in your /lib/namespace. i think that's fine while still dealing with a technical community, but it doesn't scale beyond that.
(18:05:20) mjl-: that would probably work.  though having multiple packages require editing a single file... yuck
(18:05:43) mjl-: up to now i've been just making a mess with non-base software.  luckily i'm responsible for most of them :P
(18:06:19) underspecified left the room (quit: Remote closed the connection).
(18:06:25) underspecified [n=eric@softbank220043052007.bbtec.net] entered the room.
(18:06:47) mjl-: anothy_x: are you thinking of /opt for holding the packages?
(18:06:49) anothy_x: yeah, that's worked well for me so far, too. but i'm getting ready to make a few "public disclosures", and am looking to establish a better set of practices.
(18:06:53) mjl-: (please don't use /usr ;))
(18:06:59) anothy_x: i won't use usr.
(18:07:12) mjl-: ok ☺
(18:07:16) anothy_x: it irritates me to no end that inferno installs itself in /usr on plan9. i won't repeat that mistake.
(18:07:35) mjl-: i'm looking forward to that disclosure
(18:08:21) anothy_x: i install my inferno on /sys/inferno on plan9 (and /opt/inferno on unix).
(18:08:42) anothy_x: /sys/packagename seems not too bad on plan9.
(18:15:26) mjl-: i would put all packages in one dir deeper.  to prevent clutter & nameclash
(18:15:30) mjl-: eg /sys/ext/$packagename
(18:27:24) mjl-: is it normal for the shell to be "smart" about /env?
(18:27:50) mjl-: if i write to /env/somevar, and echo $somevar, the inferno shell won't look at /env, but just think there is no $somevar
(18:28:31) mjl-: a new shell will know about $somevar.  so it seems the shell makes an in-memory copy of /env at startup...
(18:28:37) anothy_x: yup
(18:28:43) anothy_x: rc's the same way, iirc.
(18:29:14) mjl-: a bit strange.  it means env->setenv() doesn't work
(18:29:24) mjl-: (depending on expectations)
(18:36:22) mjl-: it's probably done for efficiency?  reading/writing in /env for each variable use/assignment might be a bit too much?
(18:37:56) mjl-: well, assignments still get a write to /env it seems.
(18:43:29) anothy_x: what's the difference between ventisrv and memventi?
(18:46:50) mjl-: memventi is in unix c, ventisrv is in limbo
(18:46:57) anothy_x: ah!
(18:47:30) mjl-: ventisrv is a bit easier to start (the parameters).  with memventi you need obscure parameters calculated by calc.py
(18:47:52) mjl-: ventisrv also has some support for compression.  though it's deflate and that's not really good for venti
(18:48:41) mjl-: some day i want to have a compression algorithm that is not cpu-intensive
(18:49:48) maht: talking of compression, did you see this : http://timepedia.blogspot.com/2009/08/on-reducing-size-of-compressed.html
(18:50:16) maht: re-ordering the source files to give better gzip compression
(18:51:32) mjl-: i've read about something similar not too long ago
(18:51:45) mjl-: you can quite easily make tgz files a bit smaller by sorting the file list on extension
(18:52:10) mjl-: eg create a listing, rev the names, sort them, rev them again (this clusters by extension), then tgz them
(18:53:03) mjl-: on the inferno-os tree i think it saved somewhere between 1 and 2 mb (on 53mb or so?  but that has binary hg revlogs too, so actually there isn't more than 30mb compressable data i think)
(18:56:07) mjl-: but how much js are these guys pushing that it makes sense to optimize the compressed form?
(18:56:37) anothy_x: if you're a big site, it can make quite a difference.
(18:58:06) mjl-: i would say caching would make more of the difference
(18:58:27) mjl-: the js guys also figured out that they can use standard uri's for some js libraries
(18:58:44) mjl-: let's all wait for the first compromise of such a server :)
(19:00:26) npe left the room (quit: ).
(19:38:58) xjrn [n=jim@astound-69-42-10-25.ca.astound.net] entered the room.
(20:38:16) maht: own the local dns, all yours
(21:25:03) mjl-: dns is quit weak now.
(21:25:15) mjl-: relative to other parts of internet infrastructure
(21:25:44) mjl-: i'm not entirely convinced with dnssec... though i bet it will be much better than everything plaintext
(21:26:14) mjl-: i'm not really getting the hang of the inferno shell yet...
(21:26:44) mjl-: if {${somesubfn}} { echo good } { echo bad}  ← doesn't output a thing
(21:28:12) mjl-: that subfn does set status..
(21:31:27) mjl-: i'm doing this: cgiargs=${split `{zeros 1 1} "{cgiparse}}
(21:31:46) mjl-: if cgiparse fails, the status after that line is still empty (successful)
(21:37:50) mjl-: hmm, even just a=`{cgiparse} doesn't preserve $status of failed cgiparse.  surely that's not desirable?
(21:38:59) mjl-: i probably should read all the man pages on sh at this point...
(21:58:21) mjl-: well, i'm not trying any more "use shell scripts as cgi programs"
(21:58:47) mjl-: it seems programs in limbo are better on almost all accounts:  easier to read & write, faster, giving more control
(21:58:52) mjl-: just have to compile them.
(22:23:14) npe [n=npe@94-224-251-223.access.telenet.be] entered the room.
(22:52:15) vsrinivas: ~/win 4
(23:39:45) maht: mjl- yup, I even stopped making file servers on Inferno when I realised they were just an extra layer of marshalling around the modules
(23:41:14) mjl-: yeah, valid point
(23:44:29) mjl-: though an fs interface does have its uses.  especially when speed isn't the bottleneck
(23:45:14) maht: of course, but I just end up treating limbo as the scripting language 
(01:32:26) mennis left the room (quit: ).
(01:34:47) npe left the room (quit: ).
(02:07:35) xjrn left the room (quit: Nick collision from services.).
(02:08:11) xjrn [n=jim@astound-69-42-10-25.ca.astound.net] entered the room.
(04:29:08) underspecified_ [n=eric@softbank220043052007.bbtec.net] entered the room.
(04:45:19) underspecified left the room (quit: Read error: 110 (Connection timed out)).
(05:14:10) vsrinivas left the room (quit: "leaving").
(05:15:24) vsrinivas [i=me@rose.makesad.us] entered the room.
(06:42:11) mennis [n=mennis@65.12.170.146] entered the room.
(06:45:36) mennis left the room (quit: Client Quit).
(07:11:14) jas left the room (quit: ).
(07:15:29) jas [n=jas@adsl-69-215-39-41.dsl.chcgil.ameritech.net] entered the room.
(07:44:34) underspecified_ left the room (quit: ).
(08:48:48) underspecified [n=eric@walnut.naist.jp] entered the room.
(09:01:04) mycroftiv left the room (quit: Read error: 60 (Operation timed out)).
(09:02:52) mycroftiv [n=drabgah@h69-128-47-245.mdsnwi.dedicated.static.tds.net] entered the room.
(09:29:38) npe [n=npe@94-224-251-223.access.telenet.be] entered the room.
(10:10:49) j123m left the room (quit: "Leaving.").
(10:17:12) npe left the room (quit: ).
(10:31:20) mycroftiv left the room (quit: anthony.freenode.net irc.freenode.net).
(10:31:20) underspecified left the room (quit: anthony.freenode.net irc.freenode.net).
(10:31:20) eno left the room (quit: anthony.freenode.net irc.freenode.net).
(10:31:58) mycroftiv [n=drabgah@h69-128-47-245.mdsnwi.dedicated.static.tds.net] entered the room.
(10:31:58) underspecified [n=eric@walnut.naist.jp] entered the room.
(10:31:58) eno [n=eno@nslu2-linux/eno] entered the room.
(10:32:10) eno left the room (quit: SendQ exceeded).
(10:33:02) mycroftiv left the room (quit: Remote closed the connection).
(10:33:12) eno [n=eno@nslu2-linux/eno] entered the room.
(10:33:12) mycroftiv [n=drabgah@69.128.47.245] entered the room.
(10:47:28) npe [n=npe@195.207.5.2] entered the room.
(10:50:59) mjl-: ohhhh, blstuart seems to be working on usb for native inferno.  having it would be sweet
(10:52:32) npe left the room (quit: Read error: 104 (Connection reset by peer)).
(10:53:51) npe [n=npe@195.207.5.2] entered the room.
(12:16:46) robot12 [n=robot12@inferno.kgts.ru] entered the room.
(12:26:21) j123m [n=j1m@unas-revda.interra.ru] entered the room.
(12:47:19) j123m left the room (quit: "Leaving.").
(13:14:59) j123m [n=j1m@unas-revda.interra.ru] entered the room.
(13:15:13) robot12 left the room (quit: "Ухожу я от вас (xchat 2.4.5 или старше)").