Re: [Opensim-dev] [linux-elitists] Mono considered harmful
- Forwarded message from Rick Moen - From: Rick Moen Date: Sat, 4 Apr 2009 08:44:08 -0700 To: linux-eliti...@zgp.org Subject: Re: [linux-elitists] [Opensim-dev] Mono considered harmful User-Agent: Mutt/1.5.11+cvs20060403 Quoting Eugen Leitl (eu...@leitl.org): > IANAL, does below explanation by Adam hold water? You don't have to be a lawyer to know that it's rubbish on two separate grounds. Yes, C# is an ECMA standard. However: (1) It doesn't follow that ECMA International has any power to "forbid" patent holders from suing anyone over anything, let alone patent infringement. I mean, think about it: Does Adam think ECMA International is Microsoft Corporation's daddy? That it owns 51% of the issued and outstanding common stock? At worst, it might be possible for ECMA International to be very deeply disappointed in Microsoft's behaviour at some future point, decertify particular things, and otherwise carry out mild actions that _are_ within its power. More important: (2) In any event, ECMA International does not even _profess_ to disapprove of suing patent infringers. It merely has a "Code of Conduct in Patent Matters" (http://www.ecma-international.org/memento/codeofconduct.htm), setting ECMA policy that the group will approve standards only if it has written assurances from applicant that applicable patents will be licensed on a "reasonable, non-discriminatory basis". (That term of art is typically referred to as RAND terms.) Has Adam Frisby completely missed the last decade of standards warfare? The proprietary camp has repeatedly attempted to get the World Wide Web Consortium to start accepting "RAND" patent licensing, instead of requiring that applicants certify that covering patents will be _royalty-free_. This arm-twisting failed, because of diligent focussing of attention from open source people. W3C has stuck to its guns and insistend on royalty-free patent licensing. To spell it out: "Reasonable" means obligatory patent royalty payments. Which means no open source implementations of those standards. And that is one reason why ECMA standards can be (and often are) issued on terms hostile to open source, whereas W3C standards are reliable and open-source-friendly. Sheesh. -- Cheers, HÃggledy-pìggledy / XML programmers Rick MoenTry to escape those / I-eighteen-N woes; r...@linuxmafia.com Incontrovertibly / What we need more of is McQ! (4x80) Unicode weenies and / François Yergeaus. ___ linux-elitists mailing list linux-eliti...@zgp.org http://allium.zgp.org/cgi-bin/mailman/listinfo/linux-elitists - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Mono considered harmful
On Fri, Apr 03, 2009 at 10:13:47AM -0500, Mike Dickson wrote: > won't go into details) the worst case scenarios is that you'd not be > able to run it on Linux using Mono. If you're inclined towards floating So you're saying the worst case (which is I think is arguably likely, actually) is that OpenSim only runs on proprietary systems. OpenSim becoming Windows-only, eventually. > anxiety then this is something to worry about. Otherwise from an OpenSim > perspective there are bigger fish to fry. Like getting to 1.0... Becoming ghetto and then long-term insignificant is less important than getting 1.0 out of the door. Mmmh, okay. If you say so. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] Mono considered harmful
What was the original reason for the decision to pick .Net/C#/Mono? http://www.groklaw.net/article.php?story=20090401152339514 -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [croquet-dev] mmox-oriented [virtual world interop] meetings on Tuesday
- Forwarded message from "Mark P. McCahill" - From: "Mark P. McCahill" Date: Tue, 3 Mar 2009 11:52:42 -0500 To: croquet-...@duke.edu, Lawson English Subject: Re: [croquet-dev] mmox-oriented [virtual world interop] meetings on Tuesday X-Mailer: Apple Mail (2.930.3) Reply-To: croquet-...@duke.edu, "Mark P. McCahill" I've been following the IETF mmox effort for a bit and there is a fairly active mailing list. There are several proposal in front of the group at the moment. One is a wire-level protocol derived from the Second Life/Open Grid work: http://www.ietf.org/internet-drafts/draft-hamrick-llsd-00.txt I believe another proposal is more appropriate and interesting for the Croquet family of technologies: http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt If you want to participating in the mailing list: subscribe: https://www.ietf.org/mailman/listinfo/mmox archives: http://www.ietf.org/mail-archive/web/mmox/current/maillist.html There is also an IETF mmox jabber conference you can join with a jabber client - including the one in Croquet/Cobalt :-). This jabber chat will be active during the actual IETF meeting, so this is one option if you cannot travel to San Francisco for the meeting. I'm looking into the feasibility of streaming at least the audio from the IETF meeting into Croquet/Cobalt clients here at Duke as a demonstration of one sort of interoperability and remote participation in the meeting. jabber groupchat: m...@jabber.ietf.org archives: http://jabber.ietf.org/logs/mmox/ On Mar 3, 2009, at 10:08 AM, Lawson English wrote: >Tuesday, March 3, 9:30 AM Pacific Coast Time, we are having another >mmox-oriented meeting at ThornBridgeTown Island in Second Life. IM >Saijanai Kuhn, Tree Kyomoon or Zha Ewry in-world for the group >invite to get to the meeting place. > >http://slurl.com/secondlife/ThorneBridgeTown/156/129/25 > >One topic of discussion will be: >http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt > > >This will be followed by the monthly meeting at Zero Linden's office >hours at 1PM Tuesday, Pacific Coast Time. Two hours are blocked out >for this meeting. > >http://slurl.com/secondlife/Grasmere/171/112/27 > > > >A reminder: the IETF meeting will be March 24th, 3:20-5PM Pacific >Coast Time in San Francisco. > >We plan on having [hope to have] 2-way media and chat streaming >between the live meeting and meetings in Second Life, OpenSim, Qwaq/ >Croquet, Forterra as well as a Metanomics style interactive webpage >and irc/jabber groups linked to the local chat of each world/sim. > > >See you there. > > >Lawson >Saijanai Kuhn in Second Life >Informal mmox links page: http://wiki.secondlife.com/wiki/MMOX - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] [croquet-dev] mmox-oriented [virtual world interop] meetings on Tuesday
- Forwarded message from Lawson English - From: Lawson English Date: Tue, 03 Mar 2009 08:08:12 -0700 To: croquet-...@duke.edu Subject: [croquet-dev] mmox-oriented [virtual world interop] meetings on Tuesday User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Reply-To: croquet-...@duke.edu, Lawson English Tuesday, March 3, 9:30 AM Pacific Coast Time, we are having another mmox-oriented meeting at ThornBridgeTown Island in Second Life. IM Saijanai Kuhn, Tree Kyomoon or Zha Ewry in-world for the group invite to get to the meeting place. http://slurl.com/secondlife/ThorneBridgeTown/156/129/25 One topic of discussion will be: http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt This will be followed by the monthly meeting at Zero Linden's office hours at 1PM Tuesday, Pacific Coast Time. Two hours are blocked out for this meeting. http://slurl.com/secondlife/Grasmere/171/112/27 A reminder: the IETF meeting will be March 24th, 3:20-5PM Pacific Coast Time in San Francisco. We plan on having [hope to have] 2-way media and chat streaming between the live meeting and meetings in Second Life, OpenSim, Qwaq/Croquet, Forterra as well as a Metanomics style interactive webpage and irc/jabber groups linked to the local chat of each world/sim. See you there. Lawson Saijanai Kuhn in Second Life Informal mmox links page: http://wiki.secondlife.com/wiki/MMOX - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
On Fri, Feb 20, 2009 at 05:30:57AM -0500, Frisby, Adam wrote: > Client libraries and things are usually needed. As far as I know GPL viral clause doesn't apply if you just use the API, or don't link the code statically. Notice that I'm not wedded to Tahoe. It's just this is the only system with the required capabilities I'm aware of. http://lwn.net/Articles/280483/ The Tahoe secure filesystem By Jake Edge April 30, 2008 The Tahoe filesystem is designed as a secure, distributed filesystem that is available as free software. Tahoe is also designed for fault tolerance so that data remains available even in the presence of missing or malicious peers. In March, the project released a 1.0 version which makes this a good time to take a peek. The basics of Tahoe are somewhat similar to GNUnet or Freenet in that the data is encrypted and spread around to multiple nodes in the network. Unlike those, though, Tahoe does not seek to provide anonymity. The nodes making up a Tahoe filesystem are called a "grid". Grids consist of some number of peers acting as storage server nodes along with an "introducer" that knows all of the other nodes and is the central point of contact for the grid. Files are stored in Tahoe by first being encrypted on the local machine using AES. They are then broken into "shares", ten by default, that are distributed to different servers in the grid. Before that happens, though, the encrypted file is encoded in such a way that the whole file can be recovered even if only a subset of the shares can be retrieved. This encoding, known as "erasure coding", is the key to the fault-tolerance of the Tahoe system. By default, Tahoe encodes the shares such that retrieving three of the ten is sufficient to recover the entire file. It also increases the size of the file by the expected 10/3 ratio. The suggested use case for Tahoe is a "friendnet" where some group of friends share their storage with each other in a way that reduces or eliminates the need for backups. Tahoe also has ways to share data in either read-only or read-write (immutable or mutable in Tahoe-speak) modes. Tahoe is used as a commercial backup system by Allmydata, sponsor of the Tahoe project. Tahoe is designed to be secure, which means that it protects the integrity and confidentiality of the data stored in it. SHA-256 is used extensively to ensure consistency of the plaintext, ciphertext, and shares. Files stored in the system are identified by long identifiers called capabilities, that look something like: URI:CHK:yeyur23dw7cg3mxmsl2kiqvtt4:sdtrgczwtntzyfg2uapbfytxvyqsn45j4jpgrhcey7ebzpaoznya:3:10:107833344 For mutable files, there are two versions of the capability, one that allows only reading, while the other allows writing as well. Anyone who does not have a capability string for a particular file cannot access it at all. Multiple user interfaces are available for Tahoe, including a web interface, a command-line interface, a FUSE extension and a web API. Tahoe is written in Python, using some C extensions for efficiency. It uses the Twisted framework for event handling, pycryptopp (a Python interface to the Crypto++ library) for its encryption needs, and zfec for the erasure coding. All of the Tahoe code is available under the GPL. Installing Tahoe was fairly straightforward—there were a few hiccups which have since been resolved—using the installation guide. Joining the test grid was as easy as putting an introducer identifier into a file and starting Tahoe from the command line. In some basic testing, it seems to work quite well, overall, though it did not seem to use available bandwidth as efficiently as it might. This brief overview only scratches the surface of the information available about Tahoe; there is much more on the documentation page. For anyone interested in distributed, secure, and/or fault-tolerant filesystems, Tahoe is definitely worth a look. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
On Fri, Feb 20, 2009 at 05:32:00AM -0500, Frisby, Adam wrote: > It's for use in a trusted environment only. How much can you trust 1 random strangers who can run OpenSim servers in a hypergrid and do? > You can't have an asset cluster in an untrusted environment > without replicating every asset across every host -- otherwise I recommend you look at what Tahoe does. > someone could setup, run for a while, then deliberately corrupt I really recommend you look at what Tahoe does. > the hard disk. Given enough machines doing this, you could permanently wipe > assets. It is not realistic to assume that most hosts are malicious. Notice that this is the time where bad design decisions could wind up cemented for good. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
On Thu, Feb 19, 2009 at 09:44:32PM -0500, Frisby, Adam wrote: > I'm using Project-Voldemort(.com) for the new osgrid server - it can be cross > compiled into C# via IKVM and works just fine. It's newish, but it's got some > very nice promising features and it's pretty damn fast. How well does it handle deliberate data corruption (aka malicious nodes)? -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
On Thu, Feb 19, 2009 at 02:35:47PM -0800, Kyle Hamilton wrote: > Aside from the fact that it's GPL? How is that relevant if you're not linking to it? -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] oddities with asset storage
STALLATION Tahoe works on Linux, Mac OS X, Windows, Cygwin, and Solaris, and probably most other systems. Start with "docs/install.html" [9]. HACKING AND COMMUNITY Please join us on the mailing list [10]. Patches that extend and improve Tahoe are gratefully accepted -- the RoadMap page [11] shows the next improvements that we plan to make and CREDITS [12] lists the names of people who've contributed to the project. The wiki Dev page [13] contains resources for hackers. SPONSORSHIP Tahoe is sponsored by Allmydata, Inc. [14], a provider of commercial backup services. Allmydata, Inc. created the Tahoe project, and contributes hardware, software, ideas, bug reports, suggestions, demands, and money (employing several Tahoe hackers and instructing them to spend part of their work time on this Free Software project). Also they award customized t-shirts to hackers who find security flaws in Tahoe (see http://hacktahoe.org ). Thank you to Allmydata, Inc. for their generous and public-spirited support. Zooko Wilcox-O'Hearn on behalf of the allmydata.org team Special acknowledgment goes to Brian Warner, whose superb engineering skills and dedication are primarily responsible for the Tahoe implementation, and largely responsible for the Tahoe design as well, not to mention most of the docs and many other things besides. February 13, 2009 Boulder, Colorado, USA [1] http://allmydata.org/trac/tahoe/browser/relnotes.txt?rev=2789 [2] http://allmydata.org/trac/tahoe/browser/NEWS [3] http://allmydata.org/trac/tahoe/browser/docs/known_issues.txt [4] http://allmydata.org/trac/tahoe/wiki/RelatedProjects [5] http://allmydata.org/trac/tahoe/wiki/Dev [6] http://allmydata.org/trac/tahoe/wiki/UseCases [7] http://allmydata.org/trac/tahoe/browser/COPYING.GPL [8] http://allmydata.org/source/tahoe/trunk/COPYING.TGPPL.html [9] http://allmydata.org/source/tahoe/trunk/docs/install.html [10] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev [11] http://allmydata.org/trac/tahoe/roadmap [12] http://allmydata.org/trac/tahoe/browser/CREDITS?rev=2677 [13] http://allmydata.org/trac/tahoe/wiki/Dev [14] http://allmydata.com -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
On Thu, Feb 19, 2009 at 05:23:04AM +, Melanie wrote: > You can't currently hard-limit anything. We have seen 20+ avatars in > regions with 6000+ prims on less memory than that. Was that Mono, or .Net? > Generally, avatars take more memory than prims. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Hardware Requeriments
On Thu, Feb 19, 2009 at 03:46:58AM +, Melanie wrote: > As a rule of thumb, 256MB per sim is an operative minimum, but mono > really likes to see 1GB per region to be happy. > > Some people use VPS to run OpenSim in, I don't recommend that,though. Depends on the virtualization technology. Linux VServer seems to do fine. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] [croquet-dev] meeting today for arranging media links for MMOX BOF meeting
- Forwarded message from Lawson English - From: Lawson English Date: Wed, 18 Feb 2009 14:08:59 -0700 To: croquet-...@duke.edu CC: "Meadhbh S. Hamrick (Infinity Linden)" , David W Levine Subject: [croquet-dev] meeting today for arranging media links for MMOX BOF meeting User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Reply-To: croquet-...@duke.edu, Lawson English Hey all, sorry this is being sent out so late but we arranged the time at the last second. Background: mmox is a proposed working group for the IETF that will have a Birds of Feather meeting in March at the IETF 74 meeting. mmox stands for "Massively Multiplayer Online X" [stuff] and is meant to be a general working group to design interoperability protocols between various virtual worlds. A meeting will be held today (Wed, Feb 18, 2009) at 4PM Pacific Coast Time in a Second Life venue to discuss the details/requirements for setting up 2-way video streaming of the March BOF meeting to/from participating virtual worlds. Media stream meeting: http://slurl.com/secondlife/Levenhall/89/205/105 The info about MMOX is found here: http://wiki.secondlife.com/wiki/MMOX Hope someone can attend and sorry for the last second notification. The BOF meeting is still in the BOF planning stages... ;-) Lawson English (Saijanai Kuhn in Second Life) - End forwarded message ----- -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [Opensim-users] hypergrid teleports andnon-hypergrid simulators
On Mon, Feb 02, 2009 at 05:12:38PM -0800, Brianna wrote: > >What we plan to do at our next Regatta is use an Amazon cloud for the >event and HG to it. We ran yesterday's regatta on an EC2 instance and How much do you expect to pay to instantiate a single-event in EC? >it had excellent xscript performance. This will further accomplish >total removal of neighbor region laggy influences and superior load >handling. What is the network neighbourhood for two or more instances? I understand EC2 only has good network topology for US clients, though this might have changed meanwhile. >It has been reported that LL's Blake Sea opening event, yesterday, was >a technical disaster and our OSG vastly out performed them... ty dev >team -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] weird idea #1: lightweight agent/ spectator
On Mon, Jan 26, 2009 at 11:21:15AM +0100, Dirk Krause wrote: > So what I think what would be valuable is a 'lightweight agent' > construction. This would be an AV that basically can't do much except I typically use a 6DOF-controlled flycam to circumvent issues with clunky avatars. It would be nice to highlight the flycam position with a minimal marker, like a point of light with an optional avatar label or something. How is the sound broadcast implemented in the server? > listening/watching/reading, she especially couldn't rezz anything. It's > a bit like the 'spectator mode' in some games. This way there could be > big numbers of watchers, thus giving more people the opportunity to > attend a meeting - practically increasing the number of virtual beings > in a region, without bringing the region down. > > I could think of at least two ways to acchieve this: > - a camera woman AV that 'lightweight agents' could hook up to, using > the client only as a viewer; this would be a bit like a video stream, > just with less impact, since the rendering is still done in the viewer. > - a stripped down agent that got rid of everything that causes too much > stress on either network or server. Unfortunately I don't know how to do > that because I don't know the OpenSim construction enough. These > lightweight agents could have a representation (a sphere?) while they > are online, a distinct place and the ability to look around and maybe > move slowly. > > By having something like that we could get rid of the 'theres just a > small number of AVs in every region' dilemma. -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] new Mono
http://tirania.org/blog/archive/2009/Jan-20-1.html ... Mono's new engine generates much better code than the version found in Mono 2.0. Speed: The engine will mostly benefit computationally intensive code, usually between 10% and 30% performance increase, with some cases going up as high as being 50% faster. Code size: the new engine generates slimmer code, typically 12% to 20% smaller code generated. Check out some of the benchmark results. ... SIMD Using SIMD for accelerating certain floating point operations had been in the back of our minds for a while. We looked into implementing that in our old engine, but that turned out to be very difficult. With the new engine, Rodrigo was able to put together a prototype in a weekend (the legend goes that Rodrigo's wife was busy that weekend). This prototype was later turned into Mono.SIMD an API for accelerating vector operations. Mono 2.2 is the first release to officially support and distribute it. To learn more about Mono.SIMD support, you can see this blog entry. ... -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Technical assessment of Cable Beach asset server
On Thu, Jan 15, 2009 at 02:10:13PM +0900, Mike Mazur wrote: > Hello, > > I'd like to present my analysis of the Cable Beach[1] design & code, > with the aim to eventually use it as the official OpenSim asset and > inventory server. As an aside from the peanut gallery, it would be nice to have asset storage in a distributed cryptographic filestore like Tahoe http://allmydata.org/~warner/pycon-tahoe.html -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
