Conversation with #inferno at Mon Jul 13 04:18:34 2009 on powerman-asdf@irc.freenode.net (irc)
(04:46:14) dpb9cpu [n=dpb9cpu@97-126-215-233.slkc.qwest.net] entered the room.
(05:02:50) eno__ [n=eno@adsl-70-137-151-160.dsl.snfc21.sbcglobal.net] entered the room.
(05:10:41) eno___ [n=eno@adsl-70-137-151-160.dsl.snfc21.sbcglobal.net] entered the room.
(05:10:49) eno__ left the room (quit: Read error: 104 (Connection reset by peer)).
(05:14:27) eno left the room (quit: Read error: 110 (Connection timed out)).
(06:09:22) eno___ is now known as eno
(06:59:37) dpb9cpu left the room (quit: Remote closed the connection).
(08:20:11) dagle_ left the room (quit: Connection reset by peer).
(08:20:34) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(08:28:29) npe [n=npe@94-224-251-223.access.telenet.be] entered the room.
(09:10:16) j1m [n=j1m@unas-228.rsity.ru] entered the room.
(09:20:10) npe left the room (quit: ).
(10:06:19) npe [n=npe@195.207.5.2] entered the room.
(10:59:07) gualteri [n=unknown@crespins.disca.upv.es] entered the room.
(11:13:51) sea-gull [n=sea-gull@95-28-14-168.broadband.corbina.ru] entered the room.
(11:24:30) sea-gull left the room (quit: "leaving").
(12:52:35) maht left the room (quit: Read error: 110 (Connection timed out)).
(13:05:18) maht [n=maht__@85-189-31-174.proweb.managedbroadband.co.uk] entered the room.
(14:22:31) dagle_ left the room (quit: Read error: 104 (Connection reset by peer)).
(14:23:00) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(15:29:57) paigeadele left the room (quit: "leaving").
(16:24:08) gualteri left the room (quit: "leaving").
(17:30:08) mycrofti1 [n=drabgah@h69-128-47-245.mdsnwi.dedicated.static.tds.net] entered the room.
(17:31:28) mycroftiv left the room (quit: Read error: 104 (Connection reset by peer)).
(17:42:35) mycrofti1 is now known as myrcoftiv
(17:43:28) myrcoftiv is now known as mycroftiv
(18:33:35) dpb9cpu [n=dpb9cpu@ip65-46-56-98.z56-46-65.customer.algx.net] entered the room.
(18:38:11) sea-gull [n=sea-gull@95-28-149-99.broadband.corbina.ru] entered the room.
(19:11:41) npe left the room (quit: ).
(19:17:41) MrWGW left the room (quit: Remote closed the connection).
(19:17:44) MrWGW [n=MrWGW@74.124.206.166] entered the room.
(19:47:13) mennis [n=mennis@adsl-068-016-104-079.sip.asm.bellsouth.net] entered the room.
(20:22:40) dagle_ left the room (quit: Connection reset by peer).
(20:23:20) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(21:09:06) anothy_x [n=a@c-98-221-26-115.hsd1.nj.comcast.net] entered the room.
(21:10:24) npe [n=npe@94-224-251-223.access.telenet.be] entered the room.
(21:31:19) mennis left the room (quit: Client Quit).
(21:39:40) mennis [n=mennis@adsl-068-016-104-079.sip.asm.bellsouth.net] entered the room.
(21:42:12) gualteri1 [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(21:42:20) mennis: isn't there a dis dis-assembler?
(21:48:38) j1m left the room.
(21:50:38) mjl-: mennis: disdump, asm(1)
(21:52:34) mennis: thanks.  I couldn;'t remember disdump, I kept thinking disdep, which is obviously wrong.
(21:59:47) gualteri1 left the room (quit: Read error: 110 (Connection timed out)).
(22:02:20) gualteri [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(22:18:33) gualteri left the room (quit: Read error: 110 (Connection timed out)).
(22:20:47) gualteri [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(22:37:55) gualteri left the room (quit: Read error: 110 (Connection timed out)).
(22:40:20) gualteri [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(22:45:59) dpb9cpu left the room (quit: Remote closed the connection).
(22:57:28) gualteri left the room (quit: Read error: 110 (Connection timed out)).
(22:59:19) gualteri [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(23:17:25) gualteri left the room (quit: Read error: 110 (Connection timed out)).
(23:17:48) gualteri [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(23:36:31) gualteri1 [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(23:37:14) gualteri left the room (quit: Read error: 110 (Connection timed out)).
(23:53:33) gualteri1 left the room (quit: Read error: 110 (Connection timed out)).
(23:56:26) gualteri [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(00:02:37) anothy_x left the room (quit: "Leaving.").
(00:13:40) gualteri left the room (quit: Read error: 110 (Connection timed out)).
(00:14:03) npe left the room (quit: ).
(00:25:11) mennis left the room (quit: Client Quit).
(02:07:12) sea-gull left the room (quit: Read error: 110 (Connection timed out)).
(02:22:48) dagle_ left the room (quit: Success).
(02:23:22) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(02:38:49) mennis [n=mennis@adsl-158-220-153.asm.bellsouth.net] entered the room.
(02:59:05) anothy_x [n=a@c-98-221-26-115.hsd1.nj.comcast.net] entered the room.
(03:19:47) anothy_x left the room (quit: Read error: 110 (Connection timed out)).
(05:12:17) mennis left the room (quit: Client Quit).
(05:51:19) mennis [n=mennis@adsl-158-220-153.asm.bellsouth.net] entered the room.
(06:09:12) mennis left the room (quit: Client Quit).
(07:47:13) mennis [n=mennis@adsl-158-220-153.asm.bellsouth.net] entered the room.
(07:54:10) mennis left the room (quit: Client Quit).
(08:20:56) dagle_ left the room (quit: Success).
(08:21:34) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(09:24:25) sea-gull [n=sea-gull@95-28-15-227.broadband.corbina.ru] entered the room.
(10:03:54) npe [n=npe@195.207.5.2] entered the room.
(12:03:23) maht left the room (quit: Read error: 104 (Connection reset by peer)).
(12:07:42) maht [n=maht__@85-189-31-174.proweb.managedbroadband.co.uk] entered the room.
(12:15:52) Fish [n=Fish@AVelizy-152-1-18-197.w82-120.abo.wanadoo.fr] entered the room.
(13:12:46) gualteri [n=unknown@crespins.disca.upv.es] entered the room.
(13:13:26) yiyus: wtf?! http://www.businessinsider.com/the-other-operating-systems-2009-7/inferno-operating-system-6
(13:46:18) npe left the room (quit: Read error: 60 (Operation timed out)).
(14:07:52) sea-gull: 14:13 < yiyus> wtf?! http://www.businessinsider.com/the-other-operating-systems-2009-7/inferno-operating-system-6
(14:07:56) sea-gull: 14:46 -!- npe [n=npe@195.207.5.2] has quit [Read error: 60 (Operation timed out)]
(14:13:36) Fish: linux is also in the list
(14:13:39) Fish: funny :)
(14:21:14) dagle_ left the room (quit: Connection reset by peer).
(14:21:47) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(15:18:13) mjl-: Fish: yeah :)
(16:06:52) mennis [n=mennis@adsl-068-016-104-079.sip.asm.bellsouth.net] entered the room.
(16:58:02) uriel: what, no plan9?!?!?
(17:17:04) mjl-: yeah, linux is more dead than plan 9!
(17:25:28) uriel: haha
(17:29:27) mjl-: to be fair, they're talking about the desktop-version of linux ;)
(17:49:29) eekee: what is up with desktop linux? It's really hard to find a solid reason it's not as popular as Windows, except... well I heard one person say KDE is a mess and I don'tthink I need mention Gnome
(17:50:06) eekee: but the various Windows versions dont' have stunningly brilliant desktops
(17:50:32) gualteri left the room (quit: "leaving").
(17:55:52) mjl-: there is probably not enough advantage to running linux for desktop.  it might be a few bucks cheaper, but all programs are different, few commercial apps, games, etc.
(17:56:22) eekee: ya... hmm
(17:56:29) mjl-: and i don't really understand who wants to push a linux desktop.  probably there are people out there who enjoy writing apps for end-users...  i find it very boring though
(17:56:55) mjl-: i just watched a presentation on erlang
(17:57:02) mjl-: i have to see how their vm works
(17:57:05) mjl-: and other vm's
(17:57:06) eekee: It's the whole "getting rid of stinky closed source software" that does it for a lot of people
(17:57:14) mjl-: have to make a comparison between vm's and their implementations some day
(17:57:27) mjl-: eekee: yeah, but end-users don't care about that.  only a few programmers.
(17:57:38) eekee: yeah. ah well
(17:58:26) mjl-: at least it doesn't directly affect me.  so i don't care too much
(17:58:52) mjl-: besides, i don't think all open source desktop programs are necessarily more desirable than windows desktop programs.
(18:03:09) eekee: ya, they'd have to have a significant and clear advantage to be worth it
(18:04:34) eekee: I have an idea for a very different working model that might be worth it, but I want to try it before I promote it. I should be able to script up a sort of prototype in plan 9
(18:06:49) mjl-: working model for what?
(18:07:12) eekee: I dont' want email and web browser and other stuff all seperate. I want my work on X in one 'compartment', my work on Y in another, if that makes sense
(18:08:42) mjl-: not separate programs?
(18:09:30) eekee: not seperate in a This Is Your Email kind of way, no.
(18:10:44) eekee: well perhaps that doesn't matter
(18:10:59) eekee: I want to be able to pull up a workspace for plan 9 & related, another for a different subject, etc
(18:12:18) mjl-: virtual desktops! :)
(18:12:57) eekee: virtual desktops will not seperate my email
(18:13:12) eekee: nor can you easily create & delete them on the fly with most WMs
(18:13:31) eekee: or maybe you can, but...
(18:13:34) mjl-: they do if you start separate email client instances for different mboxes
(18:14:03) mjl-: you can create a script to launch all programs for your workspace at the same time
(18:14:17) eekee: insufficiently flexible :)
(18:14:18) mjl-: i just have separate pc's for the various things ;)
(18:14:22) eekee: hehe
(18:14:35) eekee: I like to keep my electricity bill *low* hehe
(18:15:05) mjl-: me too
(18:15:09) eekee: The big thing is what happens if I want to cross-link topics? Given virtual dekstops I would have to remember them by number and keep switching between them, which is Not Fun (TM)
(18:15:11) mjl-: i only have laptops
(18:15:22) eekee: I can't afford them :p
(18:15:26) mjl-: (well, and one server that i hope to phase out)
(18:15:31) eekee: I can't afford any more computers this year lol
(18:16:02) mjl-: i have 3 virtual desktops open at minimum, all fixed.  when they go over 5 in total i'm getting confused
(18:16:26) mjl-: usually because there are too many xterms with vim's in them.  acme solves that problem at least.
(18:16:35) eekee: oh that's another point, I tend to need 5-8 just to get started, if I'm going to try & use them that way :)
(18:16:49) eekee: emacs could solve the problem too
(18:17:12) mjl-: yeah, if you're into that
(18:18:51) eekee: This idea arose from a What If moment I had when using windowmaker. You know how you can hide all windows sharing a class with WindowMaker? (or all windows of an application in OS X?) Well I just thought "wouldn't it be great if I could hide all windows relating to project X." :) Then today I realised I want my email seperated the same way
(18:21:31) eekee: I really dont' want the total seperation of workspaces
(18:21:33) Fish left the room (quit: Remote closed the connection).
(20:12:51) anothy_x [n=a@adsl-99-29-34-237.dsl.bcvloh.sbcglobal.net] entered the room.
(20:23:41) dagle_ left the room (quit: Connection reset by peer).
(20:23:47) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(21:05:36) sea-gull left the room (quit: Read error: 60 (Operation timed out)).
(21:55:37) underspecified left the room (quit: ).
(22:02:00) sea-gull [n=sea-gull@95-28-131-61.broadband.corbina.ru] entered the room.
(22:48:32) mennis left the room (quit: Client Quit).
(23:14:08) npe [n=npe@94-224-251-223.access.telenet.be] entered the room.
(00:26:00) sea-gull left the room (quit: "Lost terminal").
(00:37:54) npe left the room (quit: ).
(02:24:09) dagle_ left the room (quit: Connection reset by peer).
(02:24:39) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(05:10:22) underspecified_ left the room (quit: ).
(07:44:06) eno left the room (quit: Read error: 104 (Connection reset by peer)).
(07:48:35) eno [n=eno@nslu2-linux/eno] entered the room.
(08:24:18) dagle_ left the room (quit: Connection reset by peer).
(08:24:58) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(09:18:36) underspecified [n=eric@isa7-dhcp-116-225.naist.jp] entered the room.
(09:19:17) underspecified left the room (quit: Remote closed the connection).
(09:52:04) j1m [n=j1m@kim.rsity.ru] entered the room.
(09:52:08) j1m left the room.
(10:32:56) npe [n=npe@195.207.5.2] entered the room.
(10:42:10) npe left the room (quit: Read error: 104 (Connection reset by peer)).
(10:42:19) npe [n=npe@195.207.5.2] entered the room.
(10:55:58) underspecified [n=eric@isa7-dhcp-116-225.naist.jp] entered the room.
(11:08:35) sea-gull [n=sea-gull@95-28-92-161.broadband.corbina.ru] entered the room.
(11:27:50) underspecified left the room (quit: ).
(11:41:01) gualteri [n=unknown@crespins.disca.upv.es] entered the room.
(11:41:33) j1m [n=j1m@unas-228.rsity.ru] entered the room.
(11:54:32) j1m is now known as j123m
(12:41:20) mjl-: does anyone know what the scylla webserver is that www.vitanuova.com is running?
(12:41:24) mjl-: it seems to be fast
(12:41:34) mjl-: meaning it also has a good network connection
(12:41:53) mjl-: i was just downloading the inferno snapshot with >4.5MB/s
(12:55:06) sea-gull left the room (quit: Read error: 110 (Connection timed out)).
(13:07:04) eno___ [n=eno@adsl-70-137-148-27.dsl.snfc21.sbcglobal.net] entered the room.
(13:11:32) underspecified [n=underspe@leopard175.naist.jp] entered the room.
(13:18:35) eno left the room (quit: Read error: 110 (Connection timed out)).
(13:20:25) eno [n=eno@nslu2-linux/eno] entered the room.
(13:33:10) eno___ left the room (quit: Read error: 110 (Connection timed out)).
(14:22:33) dagle_ left the room (quit: Connection reset by peer).
(14:23:00) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(15:09:16) sea-gull [n=sea-gull@95-28-181-164.broadband.corbina.ru] entered the room.
(15:10:58) gualteri left the room (quit: wolfe.freenode.net irc.freenode.net).
(15:10:58) npe left the room (quit: wolfe.freenode.net irc.freenode.net).
(15:11:05) gualteri_ [n=unknown@crespins.disca.upv.es] entered the room.
(15:46:53) npe [n=npe@195.207.5.2] entered the room.
(15:47:26) mjl-: eekee: can your mail client wrap text?  more wrapped/formatted text on 9fans would make my day!
(15:54:19) underspecified_ [n=eric@softbank220043052007.bbtec.net] entered the room.
(16:57:35) gualteri_ is now known as gualteri
(17:32:18) eno___ [n=eno@70.137.133.228] entered the room.
(17:33:02) eno left the room (quit: Nick collision from services.).
(17:33:10) eno___ is now known as eno
(17:39:16) gualteri left the room (quit: Read error: 110 (Connection timed out)).
(17:50:25) eekee: mjl-: it doesn't, and is in general pretty useless. I'm thinking of switching to acme for mail.
(17:50:55) eekee: mjl-: assuming acme either wraps or sends it to some sane backend
(17:51:00) eekee: s/to/through/
(18:00:20) sea-gull left the room (quit: Read error: 110 (Connection timed out)).
(18:24:27) uriel: 09:39 < mjl-> does anyone know what the scylla webserver is that www.vitanuova.com is running?
(18:24:30) uriel: 09:39 < mjl-> it seems to be fast
(18:24:32) uriel: who knows
(18:24:35) uriel: sigh
(18:24:35) uriel: ask inferno-list
(18:25:15) uriel: eekee: |fmt for the win
(18:41:21) sea-gull [n=sea-gull@95-28-130-81.broadband.corbina.ru] entered the room.
(18:44:51) npe left the room (quit: ).
(18:59:11) anothy_x: bah. i just got my ipEngine yesterday, but i don't have anything else with a serial port here!
(19:03:44) eekee: uriel: yeah
(19:04:28) eekee: anothy_x: heh, I'm in danger of finding myself in that position. :) usb serial?
(19:05:07) soul9: yeah, there is something to do usb→serial afaik
(19:06:27) stu8ball: surely you knew that when you ordered it.
(19:16:44) mjl-: usb->serial can be had for cheap
(19:16:57) mjl-: but still, the wait before you can use the ipengine must be annoying :)
(19:17:29) mjl-: the cool thing about the sheevaplug is that it comes with a usb connector and the usb-serial on the device itself.  not so strange for a device that wants to be small.
(19:42:56) sea-gull left the room (quit: Read error: 60 (Operation timed out)).
(19:48:56) anothy_x: i have serial at my friend's house (where my servers are). i thought this laptop here had serial on it, but am wrong.
(19:49:13) anothy_x: i have a usb->serial dongle at my friends house, too, which i'll be taking back here.
(20:24:30) dagle_ left the room (quit: Success).
(20:24:51) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(21:40:45) gualteri1 [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(21:57:56) npe [n=npe@94-224-251-223.access.telenet.be] entered the room.
(21:58:08) gualteri1 left the room (quit: Read error: 110 (Connection timed out)).
(22:00:06) gualteri [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(22:16:17) gualteri left the room (quit: Read error: 110 (Connection timed out)).
(22:17:58) gualteri [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(22:18:42) underspecified_ left the room (quit: ).
(22:34:13) gualteri left the room (quit: Read error: 110 (Connection timed out)).
(22:35:53) gualteri [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(22:52:02) gualteri left the room (quit: Read error: 110 (Connection timed out)).
(22:53:59) gualteri [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(23:11:16) gualteri left the room (quit: Read error: 110 (Connection timed out)).
(23:12:51) gualteri [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(23:26:28) mennis [n=mennis@adsl-068-016-104-079.sip.asm.bellsouth.net] entered the room.
(23:29:47) gualteri left the room (quit: Read error: 110 (Connection timed out)).
(23:31:07) gualteri [n=salva@84.123.87.7.dyn.user.ono.com] entered the room.
(23:47:22) gualteri left the room (quit: Read error: 110 (Connection timed out)).
(00:07:08) npe left the room (quit: ).
(00:11:35) mennis left the room (quit: Client Quit).
(01:10:59) underspecified_ [n=eric@softbank220043052007.bbtec.net] entered the room.
(02:22:27) stu8ball is now known as stu9
(02:23:04) andguent is now known as WTFIsGoingOn
(02:24:00) stu9 is now known as andguent
(02:24:39) andguent left the room (quit: Nick collision from services.).
(02:24:40) WTFIsGoingOn is now known as andguent
(02:24:42) andguent_ [n=stuart@aurora.ossified.net] entered the room.
(02:24:49) andguent_ is now known as stu9
(02:25:00) dagle_ left the room (quit: Success).
(02:25:39) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(04:36:02) underspecified_ left the room (quit: ).
(04:41:44) anothy_x: okay, i now have sufficient connectors, adaptors, and cables to make the ipEngine "do stuff".
(04:41:54) anothy_x: now to get a kernel working.
(05:17:17) te left the room (quit: Read error: 110 (Connection timed out)).
(07:43:21) robot12 [n=robot12@inferno.kgts.ru] entered the room.
(08:25:07) dagle_ left the room (quit: Connection reset by peer).
(08:25:10) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(09:05:56) underspecified_ [n=eric@isa7-dhcp-116-217.naist.jp] entered the room.
(09:52:33) npe [n=npe@195.207.5.2] entered the room.
(10:46:29) underspecified_ left the room (quit: ).
(10:47:36) gualteri [n=unknown@crespins.disca.upv.es] entered the room.
(10:48:59) underspecified_ [n=eric@walnut.naist.jp] entered the room.
(11:40:39) te [i=tao@gateway/shell/blinkenshell.org/x-646e0ecb82ba3516] entered the room.
(12:21:27) underspecified_ left the room (quit: Read error: 110 (Connection timed out)).
(13:18:32) robot12 left the room (quit: Remote closed the connection).
(14:25:25) dagle_ left the room (quit: Connection reset by peer).
(14:25:44) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(15:45:50) underspecified_ [n=eric@softbank220043052007.bbtec.net] entered the room.
(16:45:34) gualteri left the room (quit: "leaving").
(17:13:00) sqweek: mjl-: holy crap not blocking on ctl writes makes wm/irc feel nicer
(17:55:59) npe left the room (quit: ).
(20:25:20) dagle_ left the room (quit: Success).
(20:25:53) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(20:50:42) maht: http://news.ycombinator.com/item?id=707559 Inferno google code page posted to HN for some reason (wasn;t me
(20:51:52) stu9: the plan 9 chapter from esr's book was posted there once.
(20:52:02) stu9: the comments weren't the most positive.
(20:53:11) maht: the recent discussions have been ok, Uriels stuff gets posted regularly (using all uriels fake acocunts no doubt :>
(20:53:41) stu9: there's an account 'uriel' which is him, veyr little stuff posted though.
(20:53:54) stu9: he uses reddit more.
(21:38:03) j123m left the room (quit: Remote closed the connection).
(23:18:36) j1m [n=j1m@unas-228.rsity.ru] entered the room.
(23:18:47) j1m is now known as j123m
(00:11:33) npe [n=npe@94-224-251-223.access.telenet.be] entered the room.
(00:25:23) npe left the room (quit: ).
(01:31:37) anothy [i=none@cpe-76-189-197-62.neo.res.rr.com] entered the room.
(01:35:51) uriel: mjl-: you around?
(01:41:17) mjl-: somewhat
(01:42:28) maht: don;t try and make out you have an active RL
(01:42:55) mjl-: no way
(01:43:03) mjl-: it's "somewhat, i'm writing code"
(01:43:25) maht: that's the answer
(01:43:51) maht: though "pissing my life away on youtube" is also acceptable
(01:44:38) mjl-: i have self protection for that:  no flash nearby
(01:45:02) maht: likewise, I have to use my Android phone if I want to watch yt
(01:52:55) uriel: maht: WTF, you removed your reddit account?  http://www.reddit.com/user/maht0x0r/
(01:53:14) maht: nah, that's an old one, they recover password was broken
(01:53:24) uriel: ah
(01:53:26) uriel: what is the new one?
(01:53:45) maht:  http://www.reddit.com/user/maht
(01:53:51) maht: which actually was the first one
(01:55:08) uriel: "Linux / Windows / OSX is like choosing which dog shit to tread in"
(01:55:09) uriel: haha
(02:01:15) maht: sadly I can only claim credit for the colourful imagery not the choosing part, originally its whaty buttet to get shot by (I cant find who wrote it)
(02:01:30) maht: what bullet to get shot by
(02:04:25) mjl-: http://www.ueber.net/code/r/sha2 ← that was what i was doing just now.
(02:04:31) mjl-: will see if i can make limbo bindings tomorrow
(02:04:49) uriel: cool
(02:09:50) maht: http://dirkb.com/html/crass.html  best band ever see  HEARD TOO MUCH ABOUT for choice (in #plan9-social too cos I'm a filthy spammer
(02:25:38) dagle_ left the room (quit: Success).
(02:26:08) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(02:32:47) maht_ [n=maht__@85-189-31-174.proweb.managedbroadband.co.uk] entered the room.
(02:33:17) maht left the room (quit: Read error: 110 (Connection timed out)).
(03:10:25) underspecified_ left the room (quit: wolfe.freenode.net irc.freenode.net).
(03:10:25) eno left the room (quit: wolfe.freenode.net irc.freenode.net).
(03:10:25) yiyus left the room (quit: wolfe.freenode.net irc.freenode.net).
(03:10:25) dagle_ left the room (quit: wolfe.freenode.net irc.freenode.net).
(03:10:25) uriel left the room (quit: wolfe.freenode.net irc.freenode.net).
(03:10:25) andguent left the room (quit: wolfe.freenode.net irc.freenode.net).
(03:10:25) anothy left the room (quit: wolfe.freenode.net irc.freenode.net).
(03:10:25) mycroftiv left the room (quit: wolfe.freenode.net irc.freenode.net).
(03:10:25) underspecified left the room (quit: wolfe.freenode.net irc.freenode.net).
(03:10:25) j123m left the room (quit: wolfe.freenode.net irc.freenode.net).
(03:10:25) te left the room (quit: wolfe.freenode.net irc.freenode.net).
(03:10:25) MrWGW left the room (quit: wolfe.freenode.net irc.freenode.net).
(03:10:26) sqweek left the room (quit: wolfe.freenode.net irc.freenode.net).
(03:12:18) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(03:12:18) anothy [i=none@cpe-76-189-197-62.neo.res.rr.com] entered the room.
(03:12:18) j123m [n=j1m@unas-228.rsity.ru] entered the room.
(03:12:18) underspecified_ [n=eric@softbank220043052007.bbtec.net] entered the room.
(03:12:18) te [i=tao@gateway/shell/blinkenshell.org/x-646e0ecb82ba3516] entered the room.
(03:12:18) eno [n=eno@nslu2-linux/eno] entered the room.
(03:12:18) underspecified [n=underspe@leopard175.naist.jp] entered the room.
(03:12:18) MrWGW [n=MrWGW@74.124.206.166] entered the room.
(03:12:18) mycroftiv [n=drabgah@h69-128-47-245.mdsnwi.dedicated.static.tds.net] entered the room.
(03:12:18) yiyus [n=12427124@je.je.je] entered the room.
(03:12:18) sqweek [n=none@124-169-245-51.dyn.iinet.net.au] entered the room.
(03:12:18) uriel [n=uriel@li43-28.members.linode.com] entered the room.
(03:12:18) andguent [n=andguent@vps832469550.serverpool.info] entered the room.
(03:36:22) uriel: powerman-asdf: you around?
(05:01:54) maht_ left the room (quit: Read error: 104 (Connection reset by peer)).
(05:02:10) maht [n=maht__@85.189.31.174.proweb.managedbroadband.co.uk] entered the room.
(06:19:12) mennis [n=mennis@adsl-211-57-108.asm.bellsouth.net] entered the room.
(06:21:47) eno_ [n=eno@adsl-70-137-174-189.dsl.snfc21.sbcglobal.net] entered the room.
(06:33:37) eno left the room (quit: Read error: 110 (Connection timed out)).
(06:50:28) eno_ is now known as eno
(07:00:53) mennis left the room (quit: Client Quit).
(07:41:16) eno_ [n=eno@adsl-70-137-156-29.dsl.snfc21.sbcglobal.net] entered the room.
(07:42:11) eno left the room (quit: Nick collision from services.).
(07:42:20) eno_ is now known as eno
(07:59:58) anothy_x: sweet, i can boot a kernel on my ipEngine!
(08:00:26) anothy_x: tomorrow, a usable root filesystem.
(08:01:47) anothy_x: for now, well, the apollo 11 crew is asleep, seems like a good time for me to be, too.
(08:05:10) robot12 [n=robot12@inferno.kgts.ru] entered the room.
(08:25:59) dagle_ left the room (quit: Success).
(08:26:08) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(09:54:34) eno_ [n=eno@adsl-70-137-130-147.dsl.snfc21.sbcglobal.net] entered the room.
(10:00:05) eno left the room (quit: Read error: 110 (Connection timed out)).
(10:30:00) npe [n=npe@195.207.5.2] entered the room.
(10:31:31) npe left the room (quit: Read error: 54 (Connection reset by peer)).
(10:31:35) npe [n=npe@195.207.5.2] entered the room.
(11:05:07) mjl-: anothy_x: cool
(11:05:21) mjl-: do you have a link or info on the specs of the device?
(12:17:33) gualteri [n=unknown@crespins.disca.upv.es] entered the room.
(12:19:05) j123m left the room (quit: "Leaving.").
(12:36:32) powerman: uriel: yeah
(12:46:30) robot12 left the room (quit: Read error: 104 (Connection reset by peer)).
(12:55:23) robot12 [n=robot12@inferno.kgts.ru] entered the room.
(13:08:16) robot12 left the room (quit: Read error: 104 (Connection reset by peer)).
(13:10:19) robot12 [n=robot12@inferno.kgts.ru] entered the room.
(14:26:42) dagle_ left the room (quit: Success).
(14:26:54) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(14:35:17) j1m [n=j1m@unas-228.rsity.ru] entered the room.
(14:35:28) j1m is now known as j123m
(14:51:10) maht-wrk [n=maht@87.84.137.35] entered the room.
(15:20:49) robot12 left the room (quit: "Ухожу я от вас (xchat 2.4.5 или старше)").
(16:51:03) maht left the room (quit: Read error: 60 (Operation timed out)).
(16:58:13) gualteri left the room (quit: "leaving").
(17:11:52) maht-wrk left the room (quit: Remote closed the connection).
(17:31:58) mennis [n=mennis@adsl-068-016-104-079.sip.asm.bellsouth.net] entered the room.
(17:35:41) uriel: powerman-asdf: sorry, I just woke up :)
(17:36:08) uriel: powerman-asdf: I was just wondering if you were planning to update the 9times russian section ;)
(17:36:16) uriel: (no rush, just wondering)
(17:37:11) powerman: uriel: yeah, I'm planning. in last weeks my working mood come back to me, so I'm working about 10-18 hours per day and try to do as much as I can before working mood leave :)
(17:37:42) powerman: I'm expecting, as usually, some time later I'll work less and will have time to update 9times
(17:38:17) uriel: powerman-asdf: no worries, I'm also extremely behind in posting things to the main 9times
(17:38:33) uriel: powerman-asdf: how is inferno working out in producting?
(17:38:39) powerman: so, yeah, I'm planning to continue that work. but if there more reliable translators available - it's ok for me to share this honourable work :)
(17:40:31) mjl-: i just put up an issue on inferno-os with sha2 support
(17:40:35) powerman: it's working very well. i'm developed few simple applications - 'retrymount' (i'm thinking about renaming it to 'keepmount' which is called just instead of usual mount, execute mount itself and monitor mount's i/o stream for errors - and restart mount after error
(17:40:51) mjl-: though i have a feeling there is a libcrypt lingering somewhere.  perhaps that already has sha2
(17:42:11) powerman: and another 'mountservices', which access required service attributes as parameters and mount/unmount all matching services in given dir as per their register/unregister status in ndb/registry
(17:43:52) mjl-: powerman-asdf: on retrymount, have you seen mount -P?
(17:44:21) powerman: with these two utilities my main application always has premounted network services which it use in predefined directory if connection to services and registry available, and don't bother about any reconnection issues - required files either available in that dir or not (or return i/o error while read/write) - this is usual error-handling issues which every application should be ready for
(17:44:37) powerman: yeah, I've seen mount -P, but it's different
(17:45:55) powerman: -P is good for usual files, but for virtual files provided by services it's too dangerous
(17:45:56) maht [n=maht__@85-189-31-174.proweb.managedbroadband.co.uk] entered the room.
(17:46:30) powerman: I prefer to have usual mount executed again and all currently open files return errors on i/o.
(17:46:44) mjl-: yeah, that's true
(17:46:46) powerman: Less lazy, but more safe.
(17:46:55) mjl-: i didn't know mount -P hided that
(17:48:18) uriel: powerman-asdf: maybe that guy that maintains an inferno blog would like to contribute / move-it-to 9times?
(17:48:44) uriel: 14:38 < mjl-> i just put up an issue on inferno-os with sha2 support
(17:48:47) uriel: very cool
(17:48:54) powerman: maybe. I've proposed this idea to him some time ago... but he probably ignored it :)
(17:49:50) uriel: heh
(17:50:28) powerman: he with some other people write translations on http://ru.inferno-os.wikia.com/
(17:50:36) eno_ is now known as eno
(17:53:30) uriel: hmmm... what have they translated so far?
(17:53:39) ***uriel would like to add translated papers and so on to doc.cat-v.org
(17:54:27) powerman: I think it will be ease for you to use google translate to err.. translate that page to get answer :)
(17:55:38) uriel: hehe, good idea, sorry
(17:55:46) ***uriel should just learn russian :)
(18:00:00) uriel: powerman-asdf: hmm... bleh, they could put their stuff in doc.cat-v.org/inferno/translations/russian/ :(
(18:00:11) uriel: (or anything similar, I'm open to any suggestions
(18:00:32) powerman: I also think so. But I'm not the person who make that decidion.
(18:02:54) uriel: well, no sorries, just let them know that they are welcome to use doc.cat-v.org 
(18:03:09) uriel: (already got russian translations of quite a few plan9 things)
(18:38:29) powerman: uriel: I'm not 100% sure, but I think we speak about j123m (his usual hick is j1m, but it's probably already used in irc, as usually)
(18:38:44) powerman: hick->nick
(19:32:18) npe left the room (quit: ).
(19:39:48) uriel: powerman-asdf: ah, well, would be nice if he shows up here
(20:26:25) dagle_ left the room (quit: Success).
(20:26:32) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(20:28:10) npe [n=npe@94-224-251-223.access.telenet.be] entered the room.
(20:57:28) anothy_x: wow, i haven't set up inferno auth in forever. re-learning...
(20:58:00) Fish [n=Fish@AVelizy-152-1-36-197.w82-120.abo.wanadoo.fr] entered the room.
(21:04:31) maht: anothy_x do you keep online notes ?
(21:05:20) anothy_x: not really.
(22:30:04) jas left the room (quit: Read error: 104 (Connection reset by peer)).
(22:30:20) jas [n=jas@adsl-69-215-39-41.dsl.chcgil.ameritech.net] entered the room.
(23:15:36) powerman: Looks like I need some help. The task isn't inferno-specific, it's more general architecture design question. I'm developing service-oriented architecture for our project. End-goal is develop most services in Limbo/Inferno, but, you know, there some bugs in Inferno... so I don't like to become dependent on Inferno until I will be sure it works reliable. Because of this initial version of services designed to use TCP and json-rpc2.0 instead of Styx... and I plan to switch from json-rpc to styx while replacing initial services developed in Perl by implementation in Limbo.
(23:16:59) powerman: Example of basic services:
(23:18:19) powerman: svc.uid: provide trivial add/del API, which generate unique "uid (user id)". will be used to create/delete users (which can be admins or members or anything depending on permissions)
(23:19:46) powerman: svc.profile: profile trivial set_field/get_field/get_all_fields API, which allow other services to share some simple string data for given uid - like sharing fist/last name, email, icq, country, etc. data about members between many our projects
(23:22:17) powerman: svc.authn: provide ability to authenticate user in any ways (login/pass, openid, etc.). provide API to set login/pass/openid for given uid, passwd-like API, and API to login/logout user (login will check login/pass or openid and generate "auth ticket", which can be checked later by any other service using this service to find is that user logged in and find his uid)
(23:23:31) powerman: svc.authz: provide API to store user's permissions, contain hardcoded logic to handle permission groups and other corner cases, provide API to check is some uid has given permissions
(23:24:39) powerman: These services are very simple and good in what they doing, they are very useful for our projects, etc. It's ease to do CRUD using them.
(23:25:07) powerman: BUT. The one thing is very complex with this architecture: SEARCH.
(23:26:24) powerman: I need to provide list of users in web interface of admin area, to provide ability to search/filter/sort them... and I see *no* simple ways to do this.
(23:29:59) powerman: One way to do this - put search API in services. Very ugly idea: it will make service's API very dependent on features needed in web interface. And it doesn't solve many tasks needed in web interface just because there no ease way to JOIN (in SQL terms) data from several services while doing sort/search.
(23:33:53) powerman: Another - provide ability in web interface to keep it's own copy of overall data from all services in useful for web interface format (for ex. in SQL database). I.e. it should listen for events from interesting services and keep own database up to date with services by fetching modified data from services. This way sounds much better, because everything is still independent from other pieces, with simple, small and stable API - at cost of some data duplication and network overhead - acceptable for us things.
(23:33:55) maht: unless you mean join(1)
(23:34:44) maht: json
(23:35:52) maht: I've started making my web sites in rc shell using werc & cgi
(23:36:04) maht: http://werc.cat-v.org/
(23:37:41) powerman: But last way suffer from sync-related issues, which add a lot of complexity. For example: admin modified some record, thus send data to some remove services which handle that data, and return to list of records. But list of records (fetched already sorted/filtered from that local database) isn't synced yet with services, so admin will not see just-modified data on screen.
(23:38:41) maht: never will
(23:40:26) maht: you cant measure speed and position
(23:40:37) powerman: maht: this problem can't be solved by werc. we've a lot of projects, cluster of servers, they have to share a lot of data and (ideally) know nothing about other services. example - all websites should share user database, authorization, login/logout, etc. in some cases, websites should looks like independent things to user, but to admin there still should be single list of members, etc.
(23:42:33) powerman: to make things worse, we've different sort of applications - windows app, flash/flex app, tcp/jsonrpc-based api... they all should have access to some shared data
(23:43:47) powerman: it's just impossible to develop all these things as single application with single database - we'll die because of it complexity. so I try to split everything to small, simple and mostly independent services.
(23:46:07) powerman: and that works very well, i'd even say it works perfectly!.. until we come to list/search/sort/filter things in web interface and related sync issues - and worse thing is what even "sync" issues related only to usability of user interface, and not to application business logic
(23:47:10) powerman: so, the final question probably is "how to make usable user interface in service-oriented architecture"? at least amazon solved this...
(00:03:25) mennis left the room (quit: Client Quit).
(00:18:08) uriel: powerman-asdf: I'm not sure I understand the question
(00:18:19) uriel: but I wonder why not make the website use the json api as backend
(00:18:32) uriel: as for data respresentation on the server side, avoid SQL like the plague
(00:18:47) uriel: either use plain text files, or one of the new fashionable json dbs
(00:19:21) uriel: afaik windows apps and flash apps should be able to access json api's just fine
(00:19:33) uriel: just hide all data under the json api, and you should be fine
(00:19:48) powerman: uriel: yeah, I'm developing website using exactly json-rpc api as backend. the question is how to better implement such api for search/sort-related features
(00:20:11) uriel: hmmm... 
(00:20:43) uriel: why not use HTTP POST to send the search and sort parameters?
(00:21:05) powerman: hehe
(00:21:34) uriel: sorry, I'm sure I'm missing something
(00:21:35) powerman: it's not a problem to send params. question is how to implement service which should handle these params and do that search
(00:21:49) uriel: well, how do you store the data?
(00:21:57) uriel: (or was that the question? :)
(00:22:00) powerman: we've distributed system. all data is distributed between many services
(00:22:21) uriel: well, isn't the search specific to one service?
(00:22:56) uriel: I would look into the various bigtable-like clones out there (just stay away from the java crap ones)
(00:23:05) ***uriel wants a bigtable clone for inferno, damn it!
(00:23:12) powerman: there no single point which has all data to implement search. and developing such service, especially for seach, which will keep all data (by fetching it from other services) and provide search/sort features become unexpectedly complex task
(00:25:30) powerman: and, as you mentioned, search is specific to one website... so we'll have to develop many such *complex* search-services - at least one for each of our websites (actually each website has much more than one resource to search/sort, so there will be a lot of such complex search-services on each website)
(00:29:34) powerman: we've think about bigtable and map/reduce things, but we don't have hundreds of servers, and on 3-4 servers map/reduce will be too slow because it does full lookup on all data for each request
(00:29:47) uriel: there is mapreduce for inferno...
(00:30:04) powerman: couchdb looks more suitable, but it isn't released/reliable yet
(00:32:33) powerman: to make my example more infernish, let's imagine we've huge amount of services registered in ndb/registry, and huge amount (up to 100_000) users in auth/keyfs
(00:33:10) powerman: and now we've to provide web interface to lists of registered services and users, with search/sort ability
(00:34:17) powerman: and without usability bugs like: admin has added new user using web interface (data was sent to auth/changelogin) but doesn't found just-added user in list of users (where admin was redirected to after submitting form with new user's login/pass)
(00:34:22) powerman: that's it
(00:35:23) powerman: if we'll do 'ls /mnt/keys' and 'cat /mnt/registry/index' for each refresh of web page - everything become too slow to be usable
(00:36:35) powerman: from other view, while ndb/registry provide some api for filtering users in /mnt/registry/find, there needs in web interface for more complex search/sort features
(00:37:02) powerman: how to solve that? add each feature needed in web interface into ndb/registry?? I don't think so...
(00:38:45) powerman: run special service to provide all search/sort features for web interface, which will get it data from registry&auth services in effecient way (i.e. using events and by fetching only changed records, without fetching all database on each change)? that will work, but that service become too complex!
(00:41:32) mycroftiv: powerman-asdf: whoa, you are talking about ndb/registry and scaling up to lots of clients? sorry i missed some of the context - im doing some of this stuff but at a much less sophisticated level than your target goals
(00:43:03) mycroftiv: the question of 'how do you find and use a dynamic set of services present among a distributed group of servers, where both clients and servers can come and go freely, and indexing has to be both distributed and redundant"
(00:43:48) powerman: and this special search-service become much more complex then we add connection between registered services and users - for example, connection to registry is authenticated, so all services registered by different users (shown by ndb/registry in service file stat). sounds reasonable, yeah? NOW, we wanna show in web interface to admin which users run which services, with search/sort feature.
(00:45:23) powerman: mycroftiv: not really. I think we'll have about 100 services in registry at max, and don't expect any scalability issues at that point
(00:46:09) powerman: the question is how to create usable web inteface for managing data provided by services like registry or keyfs
(00:46:39) powerman: when where a lot of data and we can't just fetch full database of these services on each web page refresh
(00:46:57) mycroftiv: i havent worked on the web integration aspect, i have plan 9 rc scripts that are based on the inferno registry that prototype kind of a distributed DNS system for dynamic services, but its a lot less production-oriented than the system you describe
(00:51:11) mycroftiv: so the fundamental problem is going from the large amount of complex data on the backend to the usable interface presented via a web browser?
(00:52:02) powerman: yep
(00:53:13) powerman: and backend service doing it work (like registering services and providing event notifications) very well, so it doesn't looks like good idea to "fix" this issue by adding new search/sort-related API to backend service
(00:54:13) mycroftiv: i think when you talked about making a 'smart client
(00:54:32) mycroftiv: that keeps its own local data store to track what it needs to know about the overall state, that seems like a strong way forward
(00:54:44) powerman: yep
(00:55:30) mycroftiv: i understand about the sync-related issues, but that seems soluble to me
(00:55:38) powerman: but implementation of that smart client (which become backend for sort/search tasks of web interface) turned out to be much more complex than implementation of other services like registry/keyfs
(00:56:52) mycroftiv: yes - as a matter of fact what the rc scripts i mentioned are is basically such a 'smart client' for tracking a diverse set of 9p services - keep a local database, then check periodically to keep it synced, etc
(00:57:24) mycroftiv: and it isnt done at 'production level' of guaranteeing no inconsistencies, and it did turn out to be quite elaborate in practice, compared to my expectations
(00:58:23) powerman: sync issues solvable, but also add complexity: when admin submit form for creating new user to auth/changelogin, it should get back something (some 'id'?), which give him ability to ask search-service (for showing list of existing users on next page): "please give me users 20-41 (page 2) sorted by, filtered by, BUT only after you (search-service) will update your database with data I just sent to auth/changelogin - because I wanna see new user in returned list!
(01:00:31) powerman: this require changing interface of auth/changelogin... a little change, to be honest... probably acceptable change... but I stick now at exactly that point because I'm not sure this is only change which features in web interface will require from real backend services
(01:01:24) powerman: adding such 'sync id', 'transaction id', 'locks' etc. in all backend services for each new feature customer will wanna in web interface??!
(01:01:37) powerman: that doesn't sounds like good design :(
(01:02:30) mycroftiv: i would think instead of altering auth/changelogin directly, youd just have a wrapper script on both your clients and servers that handle that kind of sequencing/syncing?
(01:03:04) mycroftiv: so not just auth/changelogin, but all your system level operations would go through your client or server wrapper to allow you to control and sequence them and have triggered actions as needed
(01:03:33) powerman: probably. afterall, changelogin is just an example, in reality I use my own services, so it's ease and more efficient to add one more API than develop such wrapper
(01:03:43) mycroftiv: ok, i see
(01:04:47) mycroftiv: well, if its mostly your own services, i think designing their APIs to work with and connect to your control interface is a good idea? unless you are trying to make them as general purpose as possible, but you already describe lots of practical reasons to do so
(01:05:50) mycroftiv: it sounds like a 'no free lunch' issue to me, where you cant get rid of the need for your tools to help 'track state' and try to support the overall usage goals
(01:06:36) powerman: i don't think it's good idea. not because I'm trying to make services too general, but because there will be a lot of control interfaces and such interfaces will require new and new features... and I don't like to change backend services API for each new feature in control interface
(01:07:08) powerman: and, again, there JOIN issue
(01:07:40) mycroftiv: well, in that case you have to commit to building the complex, smart client it seems, and couple it to its own database like functionality
(01:07:40) powerman: ndb/registry keep track of services, auth/keyfs keep track of users, but in web interface admin will need to do sort of JOIN of both services/users
(01:11:10) mycroftiv: and, you think werc is unsuitable for providing the interface because youd have to write too much database like code in something like awk for the werc app/plugin?
(01:11:17) powerman: because of need to join data from different backend *before* doing search/sort, it's impossible to implement that feature just in backend service's API (btw, I've actually think about such design some time ago - sort of 'network grep' or pipeline: say to service A: get data from service B and sort/filter it in some way, then say to service B: get data from service C, etc. - that become at some point very similar to map/reduce and couchdb)
(01:11:49) mycroftiv: in other words, reinventing the database wheel along with actually writing the 'real' interface and functionality?
(01:12:45) mycroftiv: yeah i understand that the final stage you need access to data about *all* of the services, so they cant track everything locally for you, thats a good point
(01:12:59) powerman: yeah, something like that. even if my search-service will actually keep data in MySQL and execute usual SQL for sort/search, it still should fetch data from many other backend services to fill that MySQL database... and there still will be sync issues
(01:13:34) mycroftiv: well, are there multiple simultaneous controlling nodes active at once, or just a single admin controller?
(01:13:43) powerman: so, at this point it doesn't important how to actually do search - using sql, or awk, or just in memory
(01:15:49) powerman: there multiple, but their functionality is very different - for example, in usual 'admin area' admin will manage most of things, but members in their 'member area' will manage only few things - their profile, their licenses/products, etc... and, again, we've distributed system so there will be many different websites, each with different member area and different things to manage (but they all will use same 10-15 backend services to keep that data)
(01:16:18) mycroftiv: ok, so there are 'inherent' race possibilities in managing the metadata,i see.
(01:17:00) powerman: yeah, but that races isn't a trouble on application business logic level, at least in most cases I think about
(01:17:17) powerman: if some data was changed from several places in same time - that's ok
(01:17:43) powerman: the only issue I see - interface usability - if user submitted some data, he expect to see it after submit
(01:18:27) mycroftiv: what about just 'cheating' and writing the same data to the 'local copy' and sending it to remote - which means you then have to later *verify* that the operation actually happened correctly remotely, but the user sees what you want them to see, at least
(01:18:40) powerman: if his data after submit was overwritten from other place by different user - that's ok to show him that NEW data instead of submitted. but it isn't ok to show him old data (because undelying search-service isn't synced yet)
(01:18:57) mycroftiv: hmm
(01:19:07) powerman: such 'cheating' will increase complexity of search-service in about 3 times
(01:19:45) mycroftiv: yeah - ok, well isnt it fundamentally again, 'no free lunch' ? - because you *have* to actually dial the remote and check before showing data
(01:19:51) powerman: that's because, even with current compexity (many code lines), search-service is pretty simple by nature: just listen for events from backend services and fetch new data
(01:20:19) mycroftiv: oh, are data updates 'pushed' by generating events that the system knows about?
(01:20:29) powerman: with local cache injected by user there arise REAL RACE on logic level, with very complex local cache invalidation logic, etc.
(01:21:16) mycroftiv: yes, i understand that - i was figuring you would toss out local cache and refresh it regularly and the temporary display was purely a 'dont confuse the user' shortcut
(01:21:44) powerman: the 'sync id' returned by backend services is less evil, compared to local cache
(01:21:56) mycroftiv: but if you need the data displayed to always be guaranteed to be an accurate copy of remote data at the time of query, you have to either actually make the call or be using a notification-on-update system, right?
(01:22:34) powerman: right
(01:24:51) powerman: 'make the call' (fetch data after storing it) is ok when we need to show *one* record of data. but not ok when we need to show sorted/filtered list. and 'notification-on-update' is these 'sync id' proposed above - simple enough solution, but require interface change of backend services, and I just panic expecting more such changes because of new interface features
(01:25:21) powerman: maybe it's just panic :)
(01:25:32) mycroftiv: well, i think something like sync id or tracking 'time of last update' or something like that is a pretty generally useful backend API feature
(01:25:59) powerman: that's true. as I said, it may be just a panic.
(01:26:16) powerman: but there some other general things... also very useful. locks and transactions.
(01:26:36) powerman: and I afraid I'll need them too at one point
(01:27:04) mycroftiv: it sounds from the description of the architecture that something like 'updated-by WHO at TIME' could give you a minimal tool to let you do transactions and locks on the client end, not at the service end
(01:28:16) powerman: yeah. I think so too, but don't really sure in this.
(01:28:50) powerman: things like managing user's balance, keeping in mind he can buy a lot of different products (managed by different backend services)...
(01:29:24) powerman: it looks like implementing transations on cliend side is still possible, but we can miss something now
(01:29:29) powerman: anyway
(01:29:39) powerman: whole point of this architecture - make everything simpler!
(01:29:58) powerman: and it really did it, before that sort/search issue
(01:30:23) powerman: next we'll have to do transations on client side
(01:30:27) mycroftiv: yes, although distributed systems with a lot of variation between nodes have some inherent complexities that are really hard to avoid
(01:30:46) powerman: what next? and is it will be really simpler after we implement all features?
(01:32:15) mycroftiv: have you tried prototyping what you want the admin/client/control interface to look like? how you want it to behave for the functionality youd *like* ? you can make your 'dream design' for the control interface and then maybe its easier to figure out what is realistic and sensible to implement?
(01:32:37) powerman: doing this right now :)
(01:34:49) powerman: a lot of things already implemented, then I come to adding sort/search... implement it, look at code size and start crying: 180 lines of perl code just to cache (in search-service style) one simple hash with all permissions existing in our system (permission name=>permission description)
(01:35:29) powerman: plus added 'by-design' race condition in user interface if we avoid implementing sync-id
(01:35:57) mycroftiv: well, search/sort/indexing is often an inherently hard problem, so i dont think that means you are doing anything wrong - searching and indexing is often the hard part 
(01:36:45) powerman: I have a hope there simpler way to do this. I'm open to any ideas, even to completely change overall architecture - if that make everyting simpler.
(01:37:41) mycroftiv: is the sort/search you are adding right now being added to your current 'client-side' program? this is perl, that is being invoked as a cgi with results displayed in browser?
(01:37:41) powerman: Maybe, there exists implementations of such sort/search things in some inferno/plan9 file servers?
(01:38:11) powerman: and maybe they had done this in simpler way? I failed to find such examples (except ndb/registry's "find" file)
(01:38:28) powerman: yep, perl/fastcgi
(01:39:43) powerman: the funny thing is I avoid usual headache with forks and manageing processes in fastcgi: my cgi doesn't do any blocking operations (like accessing MySQL) - it does all work using rpc to backend services, so everything works amazingly fast in single process using non-blocking sockets, epoll and events
(01:40:13) mycroftiv: well - maybe this doesnt change/help - but since if this is both important and an obstacle, what about refactoring the 'service update/search/index' component to be its own freestanding app running on its own dedicated server, talking to the service providers constantly, updating itself - then the browser-based client just gets a copy of the 'latest info' from the 'service database server' ?
(01:40:45) powerman: of course, event-based programming is more complex, if we compare to limbo/threads, but it anyway simpler than managing processes
(01:40:45) mycroftiv: again, maybe that refactoring doesnt change the fundamental problem, which is the preparation and maintenance and sync of said database of services
(01:41:07) Fish left the room (quit: Remote closed the connection).
(01:42:06) powerman: actually thing you explained as 'refactoring' is my original implementation :)
(01:42:15) mycroftiv: ah :)
(01:45:10) mycroftiv: id just say that synchronization and races and locks and generally managing transactions - these things are fundamental enough that adding some tools to support them on your api, a certain amount of complexity and maintaining state by clients - may be unavoidable
(01:47:09) powerman: so, such service-oriented architecture simplified a lot of things (starting from very simple single-process event-based fastcgi application, very simple backend services, etc.), but it also introduce some additional complexity like needs in such search-services and sync-id and probably other things you just listed... and it's hard to say is final result will be simpler than traditional implementation or not
(01:47:43) mycroftiv: im not sure what the 'traditional implementation' of your usage case would look like?
(01:48:06) mycroftiv: monolithic application frontend rather than independent services?
(01:48:36) powerman: it would looks err.. traditionally: many websites, each with own MySQL database, and some amount of wrapper script which trying to do their best to sync all that shit
(01:48:55) mycroftiv: oh ok, just vs sql
(01:49:08) mycroftiv: well that whole traditional web-data stack
(01:50:36) powerman: our current system implemented in similar way (many things already refactored into separate backend services, but there still a lot of monolithic code which use a lot of tables in database)
(01:51:49) mycroftiv: do you have a precise charting  of exactly what data is dependent on what other data?
(01:51:58) powerman: as result, there management headache - every website has own 'admin area', own users, etc. - but single owner to use all these admin areas, and sync headache - many needed features just not implemented because I resist to adding such features in unreliable/too complex way
(01:53:27) mycroftiv: it sounds like a certain amount of 'push down' work into the underlying-underlying services exists, but i know thats problematic because thats where it becomes your clients data and not yours
(01:53:28) powerman: data... probably yes, but I'm not 100% sure - system is big, and it's hard to keep everything in head
(01:53:51) powerman: yeah, that's very true!
(01:54:16) powerman: data sent to service A can be sent to other services by service A... and sync-id become very complex at that point
(01:54:24) mycroftiv: yes
(01:55:20) powerman: for now I think this issue should be solved by providing ability to get all that data back from service A, and not from other services it use - in this way the search-service will just listen for events from A and update only from A
(01:56:02) mycroftiv: well, to be honest it sounds to me like that pushes towards the 'independent large and complex service registry info server' kind of unavoidably - heres how i see it
(01:56:50) mycroftiv: if you commit to making a robust, high functionality app/server for doing that, you can try to have it provide a clean, simple, clear interface to the final user/admin clients
(01:57:45) mycroftiv: then, that server can then take over the job of translating that high level interface into how it communicates with the different services and how they connect to the clients systems
(01:58:12) mycroftiv: because it sounds like that layer is where the real complexity is - and it exists both in the sync, and in dealing with the diversity of interfaces at that level
(01:58:49) powerman: yep. but that server then become sort of usual monolithic system, very huge and complex - moreover, it probably will be much more complex than usual system because instead of 'just use sql' it will do a lot of unreliable and async network rpc
(01:59:14) mycroftiv: well, this is actually a lot like what happened with nemo going from Plan B to Octopus
(01:59:47) mycroftiv: grappling with these issues in plan B pushed him towards the more centralized design, his paper on planb to octopus is something like 'building a distributed system by centralizing everything' 
(02:00:10) powerman: yeah, I've read it some time ago, that sounds funny :)
(02:00:11) mycroftiv: and the Op protocol he created because of those unreliable async network rcp issues
(02:00:15) mycroftiv: rpc
(02:00:39) mycroftiv: so, this is definitely a design dilemma /fork in the road 
(02:01:04) mycroftiv: as you point out, stuff like search cant happen until you have 'collected' all the relevant data
(02:01:23) mycroftiv: so at *some* point, the independent parallel streams have to run together and be managed and dealt with as a unit
(02:01:24) powerman: map/reduce avoid that
(02:02:03) mycroftiv: well, in a way - i guess it refactors it
(02:02:17) powerman: if I had 100+ servers I'd prefer to flush all data into text files and just do map/reduce
(02:02:56) powerman: it's simple, it's general, and it's fast - but only if you have a lot of servers
(02:03:55) mycroftiv: is your quantity of data at this layer so immensely huge you need a sophisticated strategy to compute through it? i thought a lot of the issues were at 'admin layer' of the service indexing and users for that?
(02:04:09) mycroftiv: are those 'huge' data sets?
(02:05:42) powerman: having list of 100000 members, each with a lot of own properties (some complex, like licenses, statistics about last products we sell to him, etc.) it become very clear: it's impossible to do full scan/sort of that list on each web page refresh in admin area
(02:06:03) powerman: at least on our 3-4 servers
(02:08:04) powerman: but it's very ease to handle such list in non-general way: it all can be in memory of search-service, and search-service can support few indexes for that list to make usual sort/search operations in admin area very fast and ease
(02:08:35) powerman: right now I think I'll not need sql here
(02:20:58) mycroftiv: well its a really fascinating problem, 100k members i see that you do have to be pretty smart with your architecture, thats for sure
(02:25:50) maht left the room (quit: Read error: 110 (Connection timed out)).
(02:26:56) dagle_ left the room (quit: Connection reset by peer).
(02:27:19) maht [n=maht__@85-189-31-174.proweb.managedbroadband.co.uk] entered the room.
(02:27:27) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(02:53:51) powerman: mycroftiv: what about this idea: backend services will know about existings seach-services and push data to these search-services?
(02:54:51) mycroftiv: i think that is very sensible given how major a task dealing with large datasets is
(02:55:01) mycroftiv: you might as well do the processing as quickly as possible
(02:55:48) powerman: and backend-services will not return on initial rpc-call for data modification from user until they distribute all that data to all search-services... this should minimize possibility for race in user interface
(02:56:26) mycroftiv: yes, i agree - make the locking happen where the data is actually written so its taken care of
(02:58:44) powerman: the fact is, either each search-service should know all backends it need (listen events/get data), or each backend should know about each search-service... looks like equal amount of work/complexity
(02:59:20) mycroftiv: i think the clearest design - and the best way to avoid *mistakes* - is to avoid a lot of remote layers in between the critical data structures and where they are being modified
(02:59:28) mycroftiv: so i think what you are saying now is good
(02:59:29) powerman: maybe even simpler because instead of get event+get data it will be just one push data
(08:24:53) dagle_ left the room (quit: Connection reset by peer).
(08:25:14) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(11:18:12) Fish [n=Fish@AVelizy-152-1-36-197.w82-120.abo.wanadoo.fr] entered the room.
(12:35:18) mjl-: is anyone running here running freebsd?
(12:35:25) mjl-: preferably already with inferno on it
(12:37:45) mjl-: if a freebsd user has time to look at http://code.google.com/p/inferno-os/issues/detail?id=190, and see if that problem & the solution applies to freebsd too, that would be great
(13:23:59) maht: mjl- I have one at my office, wont be there until monday/tues though
(13:24:15) maht: I dont have inferno on it though
(13:27:04) maht: bah, I tried to add a comment on that page to remind me but comments is broken for my old firefox
(14:27:01) dagle_ left the room (quit: Success).
(14:27:34) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(15:13:41) mennis [n=mennis@adsl-211-57-108.asm.bellsouth.net] entered the room.
(15:19:41) mennis left the room (quit: Client Quit).
(17:02:33) Fish left the room (quit: Read error: 104 (Connection reset by peer)).
(17:56:13) mjl-: maht: perhaps you can "star" the post?
(17:56:19) mjl-: i wonder which firefox version you are running :)
(17:56:38) mjl-: maht: if i remember, i'll post a link to the issue again on tuesday or so
(17:58:26) mjl-: enough inferno-os patches for the day.  i hope i don't bore forsyth too much with them. :)
(17:59:01) mjl-: feeding time already...
(17:59:05) maht: ff 1.0.6 :>\
(17:59:37) mjl-: haha, what's that?  netscap4+patches? :)
(18:04:56) maht: it was the last one you could leave runnign 24/7 without running out of swap space
(18:46:18) soul9: anyone done a recent checkout from mercurial?
(18:46:31) soul9: i am missing /n /mnt Linux/386/lib directories
(18:50:41) mjl-: did you get the snaphost?
(18:50:43) mjl-: snapshot*
(18:50:52) soul9: ooo, yea, those are the empty directories i guess?
(18:50:56) mjl-: of directly a clone from the mercurial thing?
(18:50:58) mjl-: jups
(18:51:04) soul9: direct clone
(18:51:13) soul9: crud :-/
(18:51:41) soul9: .keep or something ☺
(18:51:44) mjl-: ok, then it's expected.  forsyth said something about making them on "mk install" (or makemk.sh).  but it's not done yet, and i don't know if the solution would be very clean and resilient.
(18:51:52) mjl-: i liked the .hgdicks suggestion :P
(18:51:56) soul9: :D
(18:52:03) mjl-: though i also appreciate hg, so can't bitch too much.
(18:52:18) soul9: hehe, good one tho
(18:52:22) mjl-: anyway, making those dirs will get you out of trouble.
(18:52:26) soul9: yep
(18:53:03) mjl-: it's a pity though that any random new potential inferno user might come across that problem
(18:54:10) soul9: .keep_this_file_because_mercurial_doesnt_keep_empty_directories_goto_bugs.selenic.mercurial.com_for_any_complaints_kthxbye
(19:27:06) anothy: the .hgdicks thing really made me laugh. who's was that?
(19:35:29) mjl-: forsyth i think
(20:00:29) anothy: wow, our native kernel tree is kinda a mess.
(20:26:54) dagle_ left the room (quit: Success).
(20:26:58) dagle_ [n=weechat@host162-104.bornet.net] entered the room.
(20:44:56) sea-gull [n=sea-gull@95-28-33-37.broadband.corbina.ru] entered the room.
(20:51:06) anothy: okay, not too awful, actualy. i just happened to look at all the bad ones first.
(21:03:36) uriel: hgdicks for the win!
(21:13:40) dagle_ left the room (quit: "WeeChat 0.2.6").
(21:24:51) anothy: anyone have an arm device running inferno?
(21:26:42) anothy: ppc is mostly done (although i can't test it right now), and i'm going to work on sparc next.
(21:27:03) anothy: pc should work once i can dig up a supported pcmcia card.
(21:27:11) anothy: (for ether)
(21:28:33) anothy: but now, yard work. no inferno on my lawnmower.
(21:31:10) mjl-: i've got an arm device
(21:33:11) mjl-: anothy: what kind of sparc do you have?
(21:33:29) mjl-: i still want to use my sparc64 some day.  first need one of those monitor conversion plugs...
(21:36:37) mjl-: small & cheap 486: http://bifferos.bizhat.com/
(21:36:46) mjl-: just saw it come by on openbsd mailing list
(21:43:43) uriel: mjl-: very cool
(21:45:33) mjl-: the flashing procedure sounds a bit tricky.  bricking devices sucks
(21:45:43) mjl-: of course you can always get a cheap 5-pack ☺
(21:48:42) uriel: hehe
(21:48:49) uriel: yea, bricking devices IMHO is not acceptable
(21:49:05) uriel: but I wonder how well that would run inferno
(21:50:58) mjl-: obviously 486 is unsexy
(21:59:06) mjl-: pretty sucky that arm requires a "business contact" when you want information on their latest architecture, armv7
(22:01:51) uriel: blah
(22:01:58) uriel: well, you got the x86 docs ;)
(22:03:36) mjl-: true enough :)
(22:03:38) mjl-: have to read them
(22:04:06) mjl-: i was going to read the arm docs.  and i figured i might as well read those with the latest updates (armv7 instead of armv6), but apparently that's too much to ask
(22:08:33) uriel: heh
(22:08:38) uriel: I'm sure the docs are somewhere online...
(22:09:59) mjl-: probably... haven't been able to find them by their documentid though
(22:10:13) mjl-: perhaps they are only in secret places that aren't being indexed...
(22:10:50) mjl-: i really need to get those setting-up-company paperworks done
(22:10:59) mjl-: have to start on them first of course
(22:11:36) uriel: heh
(22:20:28) sea-gull: uriel: hi, I haven't seen inferno reference manual on cat-v.org.
(22:20:54) sea-gull: I find it quite useful,
(22:21:28) sea-gull: maybe you could add it?
(22:21:46) mennis [n=mennis@adsl-211-57-108.asm.bellsouth.net] entered the room.
(22:23:35) uriel: sea-gull: what reference manual?
(22:23:42) uriel: sea-gull: there is http://man.cat-v.org/inferno/
(22:24:02) sea-gull: uriel: http://agni.csa.iisc.ernet.in/OperatingSystems/Inferno/Ref_Man20/index.html
(22:25:29) uriel: sea-gull: interesting, i think I had seen that somewhere before...
(22:25:44) uriel: it is extremely outdated though...
(22:26:13) sea-gull: I know, but it's systematic.
(22:26:50) uriel: got to run now, but remind me to look into it
(22:27:00) uriel: if it is not in doc.cat-v.org it should be
(22:27:25) sea-gull: ok
(22:29:09) mennis left the room (quit: Client Quit).
(22:44:46) maht: http://agni.csa.iisc.ernet.in/OperatingSystems/Inferno/ has quire a bunch of stuff
(22:44:50) maht: quite
(22:49:33) uriel: lucent-inferno.com for the win!
(22:50:10) uriel: most of that stuff is in doc.cat-v.org already though
(22:50:35) uriel: http://doc.cat-v.org/inferno/historical_documents/website/
(22:50:39) uriel: I think has most of it
(22:51:34) uriel: or perhaps not... 
(23:03:07) anothy: yard work over.
(23:03:31) anothy: mjl-: i've got a pair of javastations that both used to run inferno.
(23:03:46) anothy: i'm not certain i have the right kind of RAM for them any more (simms)
(23:03:56) anothy: i also have an Ultra 5, but that never ran inferno.
(23:04:14) anothy: now, off to clean myself up from the yard work.
(23:12:12) sea-gull left the room (quit: "Lost terminal").
(23:18:40) Fish [n=Fish@AVelizy-152-1-36-197.w82-120.abo.wanadoo.fr] entered the room.
(02:14:14) Fish left the room (quit: Connection reset by peer).
(02:18:50) anothy: just checked out that tiny 486. looks neat.
(05:56:42) uriel: mjl-: you around?
(07:20:02) eno left the room (quit: Read error: 104 (Connection reset by peer)).
(07:25:51) eno [n=eno@nslu2-linux/eno] entered the room.
(09:35:31) sav left the room (quit: Remote closed the connection).
(09:43:50) sav [n=savio@jagat.xored.org] entered the room.
(11:17:52) mjl-: uriel: am now
(11:18:02) mjl-: uriel: wasn't at 5am no :P
(11:18:17) mjl-: anothy_x: that ultra5, is that a sparc64?  i think i have an ultra5
(11:29:07) Fish [n=Fish@AVelizy-152-1-36-197.w82-120.abo.wanadoo.fr] entered the room.
(12:19:56) mjl-: "meta is murder".  i like it.
(12:20:00) mjl-: http://www.codinghorror.com/blog/archives/001282.html
(12:20:14) mjl-: though that's about blogging.  it applies to programming too.
(12:20:27) mjl-: don't write meta/framework packages, solve a real problem!
(14:04:25) maht: the difference between bombBahgdad(); and bombCity("Bahgdad");
(14:16:57) mjl-: more like perform(ActionFactory("Bomb"), CityFactory("Baghdad"))
(14:18:11) mjl-: with their implementions using factory factories of course
(14:42:01) powerman: Everything has it time and place in the world... everything! I'm pretty sure there ARE projects where such factories are most suitable way to, y'know, BUILD STUFF and SOLVE PROBLEMS. :) It's only me so limited person who never seen such projects, and probably nobody of us seen them... but they are exists, for sure! :)
(15:52:02) mjl-: that something has _a_ time and place doesn't mean all of its uses are valid ;)
(15:53:09) mjl-: i just noticed that google's codesearch doesn't index hg repo's.  not even "their own", e.g. inferno-os on googlecode.
(15:56:22) mjl-: it seems google codesearch does programming language detection by extension... lang:limbo gives lots of other files, e.g. for bc
(15:56:29) mjl-: bcpl :)
(16:02:15) mjl-: google code search doesn't seem to have lots of resources (google employees) devoted to it.
(16:41:22) mennis [n=mennis@adsl-211-57-108.asm.bellsouth.net] entered the room.
(17:44:11) mjl-: does anyone with netbsd or freebsd know if the ipv6 socket layer does ipv4-mapped-on-ipv6 addresses?  meaning if you listen on the "any address" on a ipv6 socket, you get ip4 connections too, mapped in the special ipv6 address space that holds ipv4 addresses?
(17:44:45) mjl-: freebsd's man page suggests it's off but can be enabled per socket.  openbsd has it off.  quite a pain that will be...
(17:53:11) mennis left the room (quit: Client Quit).