User:Zero Linden/Office Hours/2007 Feb 27

Transcript of Zero Linden's office hours from 2007 February 27th:

[13:03]  Jarod Godel: This is a quantum flux.
[13:03]  Jarod Godel: There are both zero lindens here yet there are no zero lindens
[13:03]  Zha Ewry: Heh
[13:03]  Khamon Fate: hi rob
[13:03]  Jarod Godel: I think we may have to relearn physics
[13:03]  Vitis Obviate: Hyea Zha
[13:03]  Zero Linden: and behold
[13:03]  Zha Ewry: I'm editing in the wiki, as I pop in here
[13:03]  Khamon Fate: hi zha
[13:03]  Jarod Godel: oh, thank god
[13:03]  Zero Linden: my wave function hath collapsed
[13:03]  Jarod Godel: a determinate state has been achieved
[13:04]  Zha Ewry: Excellent
[13:04]  Khamon Fate: sokay zero, less lag for us
[13:04]  Zha Ewry likes determinate states
[13:04]  Vitis Obviate nods helllos to Zero
[13:04]  Rob Linden: crashing your office hour, if you don't mind Zero
[13:04]  Khamon Fate: i'm so transparent after giraffe
[13:04]  Zero Linden: Rob, please!
[13:05]  Rob Linden: I can also potentially mention it on #opensl, though it looks like there are plenty of folks here already
[13:05]  Zero Linden: you could mention it after ward... and see how many show up next time (I hold it twice a week!)
[13:05]  Zero Linden smiles
[13:05]  Jarod Godel: is #opensl on freenode?
[13:05]  Khamon Fate: i keep meaning to poke in there but forget amidst screaming servers
[13:06]  Zero Linden: Joining us, Hiro?
[13:06]  Rob Linden: Jarod, #opensl is on efnet
[13:06]  Zha Ewry: Screamin servers, yes. I have a few. Wimpernig blades, in fact
[13:06]  Jarod Godel: Thanks.
[13:06]  Zero Linden: ooo - an ubuntu mug in SL
[13:06]  Khamon Fate: today's star was the library card catalog
[13:06]  Fremont Cunningham: Would be the client to - if I ever get it to compile
[13:06]  Jarod Godel puts on his hedgehog costume
[13:07]  Khamon Fate: just got the service restored, now have to yell at the hardware
[13:07]  Zha Ewry: Zero, I'm pounding on your WIKI page, at the moment
[13:07]  Zero Linden: okay - warming up my fingers.... it is getting like Seattle down here in SF
[13:07]  Zero Linden: cooool and rainy
[13:07]  Jarod Godel: :-p
[13:07]  Zha Ewry: U rusting?
[13:08]  Fremont Cunningham: Yes
[13:08]  Rob Linden: heh....it's only overcast here in Seattle
[13:08]  Zero Linden: Okay - well, let's get going.....
[13:08]  Zero Linden: Usual rules apply - and as always I'll be posting transcripts
[13:09]  Jarod Godel: Zero, in reworking the assett server, do the Lindens have any plans to use 3rd party hosting, ala Amazon's S3?
[13:09]  Zero Linden: We've almost got messages flowing between viewer and simulator in LLSD, via HTTP..... we expect to have it runing this week
[13:10]  Khamon Fate: aw, i wanted to ask the first question and save the wora'uld
[13:10]  Zero Linden: This is exciting as it marks the end of the long task we've working on to free us from the restrictions of the current message template
[13:10]  Zero Linden: When this work ships (we are aiming to be done end of March)
[13:10]  Zero Linden: we will no longer be constrained to have to update the viewers and the simulators together
[13:11]  Zero Linden: today we have to be very careful if we want to do that, and only some kinds of changes are possible
[13:11]  Zero Linden: After this ships... we'll be able to freely extend and add messages, while still allowing old viewers to connect
[13:12]  Zero Linden: Seems like a good thing all around
[13:13]  Zero Linden: We're calling this "Día de la Liberación!"
[13:13]  Zero Linden: Liberation of the Message System
[13:13]  Zero Linden: !
[13:13]  Zero Linden: Okay- that's my status - didn't mean to interrupt Jarod....
[13:13]  Zha Ewry: Besides the double update sim./viewer, what other constraints do you get rid of?
[13:14]  Zero Linden: Zha - this paves the way for allowing estate owners to decide when to upgrade thier simulator version
[13:14]  Khamon Fate: jarodshmarod
[13:14]  Zero Linden: And allows us to run parts of the live grid with beta software
[13:15]  Zero Linden: Though for those to happen, we'll need some extra internal management SW to be written
[13:17]  Mahem Rossini: at least people not playing money games
[13:17]  Zero Linden: Well, we've lost Zvh - dang - looked like a long question too!
[13:17]  Zero Linden: Mahem - I'm holding office hourse to talk about the technology of SL
[13:17]  Zero Linden: Back to Jarod's Q
[13:18]  Zero Linden: We'd like the asset system to be an interface -
[13:18]  Mahem Rossini: sorry, i leave soon
[13:18]  Zero Linden: No, you're welcome to join us
[13:18]  Zero Linden: We could put assets in S3, I suppose
[13:18]  Zero Linden: possibly even today, with some amount of coding....
[13:18]  Zero Linden: BUT
[13:19]  Zero Linden: I think really what you're asking is putting the assets in S3 and letting the viewer get them directly
[13:19]  Jarod Godel: Yes.
[13:19]  Zero Linden: And the short answer for that is not any time soon....
[13:19]  Jarod Godel: Thanks.
[13:19]  Zero Linden: Since S3 isn't going to share our authentication system....
[13:20]  Khamon Fate: Gee Jarod there's not that much coding in the whole wide world
[13:20]  Zero Linden: we'd be putting them out for all to find....
[13:20]  Zha Ewry: Zero, if you were going to try this, woudl you consider marking some items, such as long term scenasty as imutable, so you could widely cache it?
[13:20]  Zero Linden: But - we ARE
[13:20]  Zero Linden: changing things so that soon, the viewer will not be going through the simulator to get assets
[13:20]  Khamon Fate claps for Zha
[13:20]  Jarod Godel: But SL will always be the single, central asset host?
[13:20]  Zero Linden: Those will go through a capability - and be proxied directly to the asset server
[13:21]  Zero Linden: which frees up the sim, especially for textures
[13:21]  Zero Linden: Jarod - no, it won't
[13:21]  Vitis Obviate: via the agent server?
[13:21]  Zero Linden: Once we make the split where there is a cluster of services for agents, and a cluster for regions (see transcripts of two weeks ago)
[13:21]  Zero Linden: then probably each cluster will need it's own asset server -
[13:22]  Zero Linden: with probably some redudant copying of assets for reliability
[13:22]  Zha Ewry: DO I want to know what happens when that partitions?
[13:22]  Zero Linden: Zha - yes -
[13:22]  Zero Linden: I talked about it some in the first office hours
[13:22]  Zero Linden: But the biggest change is that we separate out functionality which is now all handled by the sim
[13:22]  Zha Ewry: (ah I'll go look at the transcript, hadn't noticed that)
[13:23]  Zero Linden: See, the sim is right now both managing the region (simulation, physics, land),
[13:23]  Zero Linden: AND it is managing all the agents that are in the sim (IM, L$, groups, etc...)
[13:23]  KKFK Allen: hi
[13:23]  KKFK Allen: kann hier jemand deutsch???
[13:23]  Zero Linden: (S'ok, I don't mind talking about this split more ... it is going to be focus of my work for the next year!)
[13:23]  Khamon Fate: Zero, are you guys migrating the "official" inworld transaction database to a web server?
[13:24]  Khamon Fate: Oh sorry, is that the split?
[13:24]  Zero Linden: khamon - are you referring to the recent blog post?
[13:24]  KKFK Allen: ;-)
[13:25]  Khamon Fate: yes
[13:25]  KKFK Allen: can yoeu speak german?
[13:25]  Zero Linden: There is a short term project (~months) to move the L$ transactions from the central DB, to on
[13:25]  KKFK Allen: ok
[13:25]  Zero Linden: to one where the data is stored in the inventory databases
[13:25]  KKFK Allen: no problem
[13:25]  Khamon Fate: oh okay, i'm seeing
[13:26]  Zero Linden: But later,
[13:26]  Khamon Fate: will our clients access that inventory database directly then to retrieve lists and transactions et al
[13:26]  Zero Linden: the transactions will be stored in the "Agent Domain" - the cluster that serves a group of agents
[13:26]  Zero Linden: That is more scalable, but as you can imagine, the bookkeeping is a bit harder then when you have one balance book!
[13:27]  Zha Ewry: Will there be any "in world" clustering for the agent domains? Will they reflect agents on nearby sims, or just spread out at random?
[13:27]  Khamon Fate: oh, y'all are actually gonna tie inventory and such records to user accounts
[13:27]  Khamon Fate: i'm impressed
[13:27]  Zero Linden: Short term, clients will still go through the sim... which will get it from the right inventory
[13:27]  Zero Linden: Mid term, the clients will have a capability, which will directly proxy to the right inventory server's web server
[13:27]  Hiro Market: do you have any structure diagrams of all this online anywhere?
[13:27]  Zero Linden: Long term - your client will get that information from your avatar's Agent Domain
[13:27]  Khamon Fate: i thunk that land-based everything was going to be the Linden method for time immemorial
[13:28]  Zero Linden: Well - for the simulation, yes....
[13:28]  Khamon Fate: This *is* exciting news
[13:28]  Zero Linden: But agents clearly don't scale the same
[13:28]  Zha Ewry grimaces land based was going to scale less and less well
[13:28]  Zero Linden: And it is expensive to keep handing off responsibilty for an agent as the agent moves around
[13:28]  Zero Linden: and lastly, leaves the system with nothing to talk to when you are logged out....
[13:29]  Jarod Godel: too bad you can't treat agents like wifi laptops
[13:29]  Zero Linden: So each sim must also manage any agents that aren't logged in, if they need to communicate with them
[13:29]  Khamon Fate: yhuh, it'll be nice to have user-based systems to handle user-based data
[13:30]  Zero Linden: Jarod - In a sense we will - The agent domain becomes the "real" agent. It can "visit" any region (the simulator), and interact with it
[13:30]  Jarod Godel: give them an ip when they're logged in, route to that, then release when they log out.
[13:30]  Zero Linden: if anyone (agent, or other region) needs to talk to it, it will now be able to address the agent domain dorectly
[13:30]  Zero Linden: directly - rather than doing all the extra work to handle the case of agents not logged in
[13:31]  Zero Linden: Jarod - we will for services which are only valid when logged in - but
[13:31]  Khamon Fate: so y'all will be popping up agent domain servers as you increase account load, just like you add land simulators now
[13:31]  Zero Linden: for other services, those that are always valid (you can always give someone inventory, for example), those
[13:31]  Jarod Godel: Message send: "hi dude" to: Jarod Gode
[13:31]  Zero Linden: will have a public, well known service (read: URL!)
[13:32]  Zero Linden: It then becomes the Agent Domain's responsibility to see if you are logged in (on an agent server) and pass the IM along, or otherwise hand it to the agent's data store for stoarge
[13:32]  Zha Ewry: Question: You've got a class of objects in the world, with very simialr needs (logn running scriptied objects) any possibility of getting them moved to a simialr domain, in the futrue?
[13:32]  Jarod Godel: By "storage" do you mean "email forwarding"?
[13:32]  Zero Linden: Zha - since those objects are tied to land, the simulator serves as a natural place for them
[13:33]  Zero Linden: Though
[13:33]  Zha Ewry: I'd love to be able to say "This scripted object isn't moving, but is long running, give it a home off the server"
[13:33]  Zero Linden: in the case of vehicles, that has obvious problems, and we are back to the hand off issue again
[13:33]  Zero Linden: Zha - that we have today, already - the long running scripted objects, you'll notice that their ID stays the same even if the region goes down and comes up
[13:33]  Zha Ewry: Right, sure. Scripts in vehicles, and attached to Agents, aren't sensible. But we have stores full of staic
[13:34]  Zha Ewry: scrpted objects
[13:34]  Jarod Godel: Zha, but if the prim is an object, shouldn't it run its own scripts?
[13:34]  Zha Ewry: which drag down the sims
[13:34]  Zero Linden: So, they should have a permanent messaging port (read: URL again) that will be keyd off the region name (or ID) and the region domain they are in
[13:34]  Khamon Fate: yes jarod but the prim is still in the sim's RAM and the script is still running in the sim's RAM
[13:34]  Khamon Fate: and sim's still have to hand off scripted objects
[13:35]  Zero Linden: Imagine: http://services.regions.secondlife.com/Grasmere/objects/1234
[13:35]  Zha Ewry: Right, and if you look atwhat kills a sim, among many thigns, its active scripts. (I've stood under a 5500 prim obejct with scripts in each prim. Time dialation was around .5, with 2 agents in the sim)
[13:35]  Zero Linden: and again, it would be the region domain's job to see if the region was up, and so route the message, or if down, store it...
[13:35]  Khamon Fate: seperating the user data and services from the simulator data and services is enough. don't make this more complex than it necessarily is.
[13:35]  Zero Linden: Ah - well finding ways to give more CPU time for a single region is another story....
[13:36]  Zero Linden: The communications channel between scripts, and the objects and other state of the world is not messaging based at present -
[13:36]  Zero Linden: al C++ APIs
[13:36]  Zero Linden: *all
[13:36]  Zha Ewry winces
[13:36]  Zero Linden: so, moving script processing to another process, or CPU, or machine would be difficult
[13:36]  Zha Ewry: So, scripts aren't moving any time soon.
[13:37]  Zero Linden: No
[13:37]  Zha Ewry: You could proxy out all the C++ calls.
[13:37]  Zha Ewry frowns
[13:37]  Zha Ewry: Pretend I didn't say that. You've done smalltalk
[13:37]  Zero Linden: But I could see, a year down the line, it being much easier for us to have machines with beefy memory or CPUs for script laden sims
[13:38]  Zero Linden: Ah yes - we could put a CORBA wrapper around all the C++... and then wrap it all in SOAP... and... and...
[13:38]  Jarod Godel: I hope down the live, you guys just use virtual machines to load balance this kind of thing.
[13:38]  Jarod Godel: *line
[13:38]  Zero Linden starts to drool
[13:38]  Zero Linden: Jarod - since we are giving a full CPU to each region - I'm not sure that virtual machiens would help
[13:39]  Khamon Fate: so we'll have regions of sims being served by region domain servers, and groups of avs being served by account domain servers
[13:39]  Zero Linden: we do already have the ability to bring up regions on whatever hardware we have - so regions are not tied to specific machines
[13:39]  Jarod Godel: Zero, you couldn't just run 4 "single cpu" virtual servers on a quad-core machine?
[13:39]  Khamon Fate: and the only single point of failure will be the singular space (grid) server
[13:39]  Zero Linden: Jarod - that is exactly what we do do today - just w/o the VM software
[13:40]  Zha Ewry: Jarod, that woould only benefit if the sim code is nicely decoupled, so it doesn't spend most of its time waiting on locks
[13:40]  Jarod Godel: But with virtualization, couldn't you shift resources faster to deal with script-laden sims?
[13:40]  Zero Linden: What would be better with VM vs. just running four processes?
[13:40]  Zha Ewry: VM doesn't magically make that go away
[13:40]  Jarod Godel: see my previous statement
[13:40]  Zero Linden: Hmmmm. no, actually, since without VM, they easily take as much memory as they need?
[13:40]  Zero Linden: *!
[13:41]  Khamon Fate: don't simulators essentially act as VMs
[13:41]  Zero Linden: With VM - we'd have to adjust VM parameters as they are running
[13:41]  Zha Ewry: Do you constrain the memory use of each sim on a machine, or can one starve the others?
[13:41]  Zero Linden: Khamon - exactly
[13:41]  Zero Linden: Zha - they steal
[13:41]  Jarod Godel: Can you load balance resources on a server running multiple sims? Say that Grasmere needs 75% of the memory and Zoe needs 25%?
[13:41]  Zero Linden: Which is sometimes a problem - but not nearly as much as you'd think
[13:41]  Zero Linden: Jarod - it does that automatically
[13:41]  Jarod Godel: Then I withdraw my theory.
[13:42]  Jarod Godel: Yeah. VM would just suck up extra resources. Sorry 'bout tnhat.
[13:42]  Zero Linden: What it doesn't do is decided that host123 has heavy needs and host456 has light - so rebalance by swapping some regions
[13:42]  Zha Ewry: Oh.
[13:42]  Zha Ewry: So, that may explain empty, but laggy sims
[13:42]  Fremont Cunningham: A problem for scripts at present is they are lowest priority.. anything else in a Sim starts to demand a lot of processor time, and scripts die.
[13:42]  Zero Linden: But again, current VM technologies don't really help there either
[13:43]  Zero Linden: At least for us we COULD bring donw two regions and reload 'em swapped...
[13:43]  Zero Linden: Fremont - yes, true
[13:43]  Khamon Fate: Zero, does a sim server have to run a small space server to load balance the sims on the machine? My impression was that each sim had dedicated memory and processor configurations
[13:43]  Jarod Godel: So you can "load balance" but it would require a restart.
[13:43]  Zero Linden: For us to get to a place where we can run simulators with different resource strategies, or different HW requirements, etc...
[13:44]  Zero Linden: ALL of that is predicated on being able to run a hetreogenous grid of simulators
[13:44]  Fremont Cunningham: Any plan to improve scripts share of action? Or limit people's abuse of scripting resources?
[13:44]  Jarod Godel: I still withdraw my VM suggestion. :)
[13:44]  Zero Linden: and that brings us back to Message Liberación
[13:44]  Rob Linden: the thing that might help with load balancing is having one IP per region, rather than one IP per host. VMs help with this, but aren't the only way of doing it.
[13:45]  Zero Linden: Fremon - limiting scripts is clearly a good short term thing -- and I believe there is some work on that - though not in my studio
[13:45]  Jarod Godel: Rob, so sims still, each have a real IP?
[13:45]  Fremont Cunningham: multi IP per sim machine.. Jails?
[13:46]  Zero Linden: Each host has an IP - and most hosts have four regions on them
[13:46]  Zero Linden: menu Help > About Second Life... will show you the host, IP and port of the region you are in!
[13:46]  Fremont Cunningham: So make 4 jails on the machine. 4 IPs
[13:46]  Jarod Godel nods
[13:47]  Zero Linden: We could do four IPs with just virtual interfaces (in Linux kernel)...
[13:47]  Zero Linden: but aside from the annoyance of multiple ports, the IPs aren't a big issue
[13:47]  Zero Linden: again - we don't permanently assign hosts to regions -
[13:47]  Zero Linden: so there is always a mapping layer between region and host (ip,port) that is running it
[13:48]  Fremont Cunningham ponders -- comes down the the same Ethernet Hardware.. so more IP#s dont help much. Maybe more stack is all
[13:48]  Khamon Fate: Zero are you going to SLCC this year?
[13:48]  Zha Ewry: Right, you always want to talk up the stack one indriretcion level when you can
[13:48]  Zero Linden: well - perhaps a better way to more fairly carve up the scripting resources will get at most of this...
[13:49]  Zero Linden: Everything can be solved with one more layer of indirection!
[13:50]  Mahem Rossini: fine, i haven't understood a k, but was very intersting,
[13:50]  Fremont Cunningham: Whats missing at present is good analysis tools to find out what the script loads really consist of
[13:50]  Mahem Rossini: ciao from italy
[13:50]  Mahem Rossini: keep goin, dudes
[13:51]  Vitis Obviate: so in the effort to split the messaging, will this eventuallywork its way down into things we can control or access at the script layer?
[13:51]  Zero Linden: Indeed - better tools are things we wish we had....
[13:52]  otakup0pe Neumann: Yaye. I didn't miss the party.
[13:52]  Zero Linden: Well, the split 'tween agent and region domains will result in things like capabilities that you can manage from external sources
[13:52]  Zero Linden: with will make the open source folks even happier - as they will be able to build clients with much more custom sets of functionality
[13:52]  Khamon Fate: sims already work like OS to manage scripts in space and time dedicated to the purpose without letting them hog resource.
[13:52]  Zero Linden: Khamon - well, they try to, at least!
[13:53]  Khamon Fate: any more management would probably create more overhead than help
[13:53]  Fremont Cunningham: Yes, but they fail...
[13:53]  Zero Linden: There is an important point there - sometimes the instrumentation is a resource hog
[13:53]  Zha Ewry: Zero, I'd be glad to have some lib calls for LSL which would help witht hings like saying "this is a lower priroity" script
[13:53]  otakup0pe Neumann: renice for scripts
[13:53]  Zero Linden: we already know that one aspect of the LSL VM that tries to ensure we time slice at a very fine grain
[13:53]  Zero Linden: is actually someone costly
[13:54]  Khamon Fate: then the VSIMware needs to be better automated in that respect. users could never stay ahead of that curve. it's like taking the reposibility for handling the functions of a router because it's not doing the job well.
[13:54]  Zero Linden: Zha - do you have computation that could be lower priority, or is it event driven already?
[13:55]  Zha Ewry: Some of our stuff wouldn't mind being slow. Some would.
[13:55]  Zha Ewry: We'd be glad to hint
[13:55]  Rob Linden: Khamon...there's an interesting analogy there. TCP has a backoff algorithm that stacks need to follow to deal with an overloaded router
[13:55]  Fremont Cunningham: My estimation is that anything that relies on the scripter to do thongs we//properly/nicely is doomed to failure. Already is failing.
[13:55]  Jarod Godel: Khamon, well, if more people would let me inject them with mongoose blood...
[13:56]  Hiro Market: also, I believe lists have high overhead - would not giving people the option of faster array constructs help?
[13:56]  Rob Linden: it's implemented in the stack, rather than the application layer, but /most/ TCP implementations play by the rules
[13:56]  otakup0pe Neumann: "most"
[13:56]  Zha Ewry: We sometimes have scripts which while active, don't need tol listen very often, but we're not able to indicate that
[13:56]  otakup0pe Neumann: The other part of the issue is the rules are defined, but not the implementations.
[13:57]  Zero Linden: Hilo- Personally, as the author of two langauges, and the implementor of many VMs.... I'd *love* to do a number on LSL!
[13:57]  Zha Ewry: Fremont, I think it depends. I've got sims where I control 10,000 scripts. *I* have an incetive to get it right
[13:57]  otakup0pe Neumann: (issue with TCP and the like, i'll stop my tangent now)
[13:57]  Jarod Godel: Zha, would making use of the Timer ever help there, or would opening and closing various llListen's be worse than one constant one?
[13:57]  Sifu Moraga: Hi all, got the time zone convertions wrong
[13:57]  Fremont Cunningham: LSL 'lists' process is terribly slow. Only use lists to init stuff. Or read occasionally.
[13:57]  Khamon Fate: True Rob so there's some odus on the scripters to be nice as it were, but it's still ulitmately the simulators job to properly manage the resources in it's virtual space
[13:57]  Zha Ewry: I've played a bit. Timers aren't free
[13:57]  Zero Linden: But, annoying as LSL is, it is running, and enabling tremendous things, so we're going to work that which is breaking first.... sigh
[13:58]  Jarod Godel: Zha, figures.
[13:58]  Jarod Godel: Zero, any chance LSL will ever get arrays?
[13:58]  Hiro Market: like a big please to that
[13:58]  Zero Linden: I thnk, after mono finally ships, it is more likely we'll see another language binding first... rather than extend LSL
[13:58]  Fremont Cunningham: Well.. LSL is breaking all the time. Virtually 100% of my time goes to finding work-arounds for LSL problems.
[13:58]  Khamon Fate: My trees time all listens and shut them down if there's no response
[13:59]  Hiro Market: any indication which language binding?
[13:59]  Jarod Godel: Zero, another language? Perhaps some Python maybe?
[13:59]  otakup0pe Neumann: perl ! (lol)
[13:59]  Zha Ewry: While were on LSL, I've posted to the wiki, some more detailed comments about the blobs and getting things in/out of SL that aren';t 2048 byte strings
[13:59]  Zero Linden: Fremont - I sympathize (my personal alt writes many 1000+ line LSL systems)
[13:59]  Zero Linden: but it isn't breaking as badly as, say, the database (eek!)
[13:59]  Zha Ewry: Would antoher language, with the same 16K dataspace constraint be that much better?
[13:59]  Jarod Godel: otakupOke, careful. Language snobs will descend on you like wolves if you say Perl. ;)
[14:00]  Khamon Fate: ha ha ha zero
[14:00]  otakup0pe Neumann: hehe.
[14:00]  Zero Linden: Zha - yes, probably
[14:00]  Zero Linden: Hiro - no work is being done on that front (of another language), but it would have to be one that has a compiler to MONO (CIL)
[14:00]  Hiro Market: just so long as you don't bind brainfuck first :-)
[14:00]  otakup0pe Neumann: Haha.
[14:00]  Zero Linden: Python is among those that do
[14:00]  otakup0pe Neumann: I wasn't going to make that joke, but I'm glad someone did.
[14:01]  Fremont Cunningham: For many sim now it is - Sims becoming unusable for 'fun' LSL because they are so bogged down. 'cant run script' - similar to 'cant log in'
[14:01]  Jarod Godel: Zero, so... C#, Python, Visual Basic, and... F#?
[14:01]  Zero Linden: I don't think F# is open enough for us to use... a shame, Cory has looked at F# and said he really liked it
[14:02]  Zha Ewry: Hmm I assume you still want to be the compiler of the source? (into mono)
[14:02]  Khamon Fate: zounds i gotta jet. thanks for hosting Zero
[14:02]  Zero Linden: Zha - either we have to compile, or we have to have a bytecode verifier
[14:02]  Zha Ewry: Not taking com[iled mono runtimes as binaries.
[14:02]  Zero Linden: So - guess which is easier?
[14:02]  Zha Ewry: right
[14:02]  Jarod Godel: Zha, wouldn't they have to be, since you never know what kind of chip your sim'll be on?
[14:02]  Zha Ewry: I hate to say it, but I'd rather you compile
[14:02]  Zha Ewry: No.
[14:03]  Zero Linden: Jarod - mono runs programs compiled to CIL, which is a bytecode system
[14:03]  Zha Ewry: Mono is one level up from the chip
[14:03]  Zero Linden: then it runtime compiles to native
[14:03]  Jarod Godel slaps his forehead
[14:03]  Jarod Godel: I should have known that.
[14:04]  Zha Ewry: One can argue whether is better or worse than a JVM, but its similar isolation from the chip.
[14:05]  Jarod Godel: Zha, right.
[14:05]  Zero Linden: Same technique as a JVM, really
[14:06]  Zha Ewry: Similar.
[14:06]  Zero Linden: well all - my hour is up
[14:06]  Jarod Godel: Isn't the .NET runtime (never used Mono) closer to the OS, though?
[14:06]  Zero Linden: I've got to get back to coding.... or rather, you want me to get back to coding!
[14:06]  Vitis Obviate: ty very much Zero...
[14:06]  Zha Ewry: Zero I dropped off a proposal on the wiki page, feel frree to IM me with quesions
[14:06]  Jarod Godel: Thankls, Zero.
[14:07]  Zha Ewry: Thanks, as always
[14:07]  otakup0pe Neumann: Nice talking to you Zero
[14:07]  Zero Linden: I saw it Zha - I'll try to comment
[14:07]  otakup0pe Neumann: I'll try to show up on time next time
[14:07]  Zero Linden: Same time next week, and of course Thursday morning early for the Europeans (and die hards!)
[14:07]  Zero Linden: And will be posting transcript to wiki in just a bit
[14:07]  Zero Linden: Thank you all again for coming - great to meet with you!
[14:07]  Vitis Obviate: really appriate that also
[14:07]  Zha Ewry: Excellent Zero, they really help.
[14:08]  Sifu Moraga: Great, because I missed it (I'll have to sort out the time zones.)
[14:08]  Zha Ewry: You'll have quite a store of knowledge up ther soon