Re: [opensource-dev] Script Memory Limits UI
It would be nice if everything were free, too. The issue is memory *allocation*. If a script only uses 16K but is allocated 64K, that 64K counts against the server's actual memory allocation limit. So, cool, wouldn't it be nice to only allocate what is actually requested? Well that implies rewriting a lot of code to use memory differently, and requires frequent reallocation of memory (as the needs grow or shrink). There is a real cost to this, in terms of programming effort and in terms of runtime costs. Until now, script memory has seemed to be a free lunch. Well, the free lunch is over, and we'll have to deal with it. I won't believe that it's feasible to simply "report the actual memory used" until someone who really understands Mono memory allocation and our scripting language's arrays (the main memory users) says that there actually is a feasible solution along these lines. Change causes upset. This will be an issue. IMHO, though, failing to address the problem would be worse. Regards Jeff On Sun, Mar 7, 2010 at 6:20 AM, Marine Kelley wrote: > Well we have two mutually exclusive solutions here. > > Either Mono scripts are given a hard memory limit that we (the scripters) > can change within the scripts, with all the overhead work that it implies > (i.e. modifying hundreds of scripts before issuing an update, and having to > know upfront how much memory will be taken exactly), which means that in > regards to the scripts memory usage UI, the script will use exactly as much > as the limit it has requested, no matter whether it really uses it or not. > This gives wasted memory and false information. > > Or, Mono scripts are given a hard memory limit that we cannot change, and > they report exactly as many bytes as they use at any time. But we shouldn't > be able to change the limit ourselves, because it wouldn't make sense to do > so, it would only be restraining ourselves if we set less than 64k, and > wasting memory space if we set more than 64k. > > In both cases, the question of whether the script crashes when reaching the > limit or not is not related. > > I seriously, and I mean seriously, think that choosing the first option is > going to hurt the established scripters very badly, and therefore the grid > as a whole. To me scripts should report exactly as much memory as they use, > not more, and should not require the scripters to modify them to report > something that could be computed by the sims more accurately anyway. > > Of course it is tempting to tell the scripters "you can now decide how much > memory to allow, and that way you are certain it will report the amount you > have set", as much as it is tempting to shift the workload of allocating > script memory onto the scripters since LL can't seem do it. > > Remember, we are now going to have limits on a service that didn't have them > before. For the same price. All in the sake of stabilizing the grid. Ok for > me. This will already hurt scripters who will have to adapt bad scripts. But > now we are told we are going to also adapt good scripts as well ! I repeat, > this is unacceptable. > > Marine > > > On 7 March 2010 03:02, Frans wrote: >> >> As for the dynamic vs fixed memory usage. Of course it would make sense to >> have dynamic memory usage, but I haven't seen a response yet on how to solve >> the problem that Kelly described, about scripts suddenly running out of >> available memory to use, when they fill up lists with info, etc. And break >> because of it. Or is this considered not to be a big problem? > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Script Memory Limits UI
Babbage has already said that LSO code will be "charged" 64K even though it only uses 16K. Perhaps he's changed that decision -- is that the case? Regards Jeff On Sat, Mar 6, 2010 at 9:02 PM, Frans wrote: > In response to the OP. I agree the UI will have to present that information > differently. As it is now people will merely make a decision on memory usage > and choose LSL scripts, and remove mono scripts. Likely negatively impacting > their own experience. Scripters will be driven to compile scripts as LSL for > marketing reasons, to make a product report a lower value > Preventing LL from achieving it's goal of a full move towards MONO. > > As for the dynamic vs fixed memory usage. Of course it would make sense to > have dynamic memory usage, but I haven't seen a response yet on how to solve > the problem that Kelly described, about scripts suddenly running out of > available memory to use, when they fill up lists with info, etc. And break > because of it. Or is this considered not to be a big problem? > > -- > Jeroen Frans > Virtual World Technology Specialist. > VesuviusGroup.com > SL: Frans Charming > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Script Memory Limits UI
It used to be that simple, with original LSO. With mono, it's more complicated, because two instances of the *exact* same script can share the code segments. I wonder whether this sharing ability will be taken into account. Ideally yes, because it's best when the metrics used to measure something actually reflects the thing you want to measure and optimize. Regards On Sun, Mar 7, 2010 at 8:21 AM, Marine Kelley wrote: > As far as I understand it a script (the item you manipulate in-world) is a > bytecode (a compiled version of your code without the comments, the spaces > and the returns) loaded into the sim, plus its simple, constant-size > variables (integer, floats), all of which forming the stack. Then you have > all the varying-size variables, namely strings, keys and lists, which all > form the heap. > > The 64k limit concerns the sum of the bytecode, the stack and the heap. The > size of the two former is fixed and determined at compile time, while the > size of the latter is variable. > > Someone please correct me if I'm wrong, this is experience talking, I do not > have access to the server-side code of the script handling. > > > On 7 March 2010 13:11, Tony Dodd wrote: >> >> May I ask a probably dumb question here? It's probably been answered but >> I can't find the answer now. >> >> Presumably a script uses two resources, the byte code in its assembly and >> a slab of memory allocated for its stack/heap. And am I right that the >> former can be shared between multiple copies of a script whereas the latter >> would have to be allocated separately to each script? >> >> OK, the question is, does the 64K limit refer to both of these together or >> just to the stack/heap? If I have a mono script that is quite large but >> doesn't allocate any lists, will each instance of that that runs be using up >> 64K of memory? >> >> If there's an obvious place I should look I apologise but without knowing >> this I find it hard to assess how much impact memory limits will have on my >> own scripts. >> >> Maldoror Bowman >> >> >> >> >> ___ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question regarding llSetLinkPimitiveParamsFast() function in 1.38.0
It's generally a bad idea to change behavior dramatically, and much safer to add a new function. Dramatic changes in behavior cause new bugs, or cause old but insignificant bugs to become significant. New functions don't. On Sun, Mar 7, 2010 at 9:39 AM, Obsidian Kindragon wrote: > Hi all, > > I've a quick question regarding the new llSetLinkPimitiveParamsFast() > function in 1.38.0. Why did LL opt for a new function instead of just > removing the delay from the current llSetLinkPrimitiveParams() function? > I can't conceive any case where removing the delay from the current > function would break any existing content. > > - Obsidian Kindragon (AKA Obsidian Stormwind) > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Script Memory Management Algorithm
huh? Can you point to existing technology for this analyzer? Seems to me like it would require an oracle. On Mon, Mar 8, 2010 at 2:03 PM, Michael Schlenker wrote: > > Am 08.03.2010 um 18:46 schrieb Kelly Linden: > >> We are not out to write a new malloc for mono. What we have is a system >> that throws an exception when the memory used by the script hits a certain >> threshold (64k currently). This exception is caught so we can "crash" the >> script. The future small scripts and big scripts projects will add new >> functions to set and get this threshold value, allowing scripters to >> effectively control how much memory is reserved for their script. We will >> continue to use mono's default memory management within the reserved memory >> thresholds. It is a much simpler problem to solve. >> > While your at it, how about a static analyzer for mono/LSL that determines > guaranteed lowest memory consumption for a script and sets the threshold > there. > > That would have the benefit of easing scripters work by providing useful > defaults for all the easy cases without them having to do anything at all. > > The scheme should only break down if the mono GC behaves weird. In that case > scripters have a huge problem anyway as they cannot set any threshold without > being crashed at random by a lazy GC. > > Michael > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Script Memory Management Algorithm
Please tell me how to register for this list. I was registered for sldev, but don't remember how. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Script Memory Management Algorithm
Most scripts allocate space (add items to lists) based on events. How would the number of events be estimated? Seriously, this requires more than an oracle. It requires clairvoyance. Unless the coder specically codes a limit on the number of list elements added, there is no way to predict. Lear On Tue, Mar 9, 2010 at 5:57 PM, Michael Schlenker wrote: > > Am 09.03.2010 um 02:54 schrieb Lear Cale: > >> huh? Can you point to existing technology for this analyzer? Seems >> to me like it would require an oracle. > > It might require an oracle to reach 100%, but if you go for the easy part, > its not that hard (assuming a sane GC). LSL is a pretty simple language > without many of the problems you have with C like pointers and memory > aliasing and stuff like that. Not sure if one could reuse parts of the LLVM > analyzers/optimizers for Mono to do this (Mono 2.6 can compile for a LLVM > backend). > > 1. All scripts that only handle integer, float, vector, key and rotation > variables without recursive calls can be handled easily. > --> The memory size for those types is fixed. > --> One could probably compute a complete callgraph and add up the maximum > number of used locals too. > > 2. If the script uses recursion, it depends. If the compiler can figure out > the maximum depth, works as 1, if it can eliminate tailcalls, it can do 1. > too. If it cannot, its a lost cause and it must assume the worst aka 64kB. > > 3. If the script uses strings, it depends what operations are used on those > strings. The only critical operation is appending strings to other strings, > comparing, getting substrings etc. could all be done in constant memory. As > all functions that can provide strings to a script have an upper bound on > parameter size one could calculate a 'worst case' scenario in many cases. > Just assume any LSL function or event that returns/provides a string provides > a unique string of maximum size. Sum up and you have a worst case limit. > > 4. If the script uses lists of other data types use similar techniques as for > strings. As LSL does not have any reference types and you cannot nest lists > this is not too hard to do because list are essentially flat like strings. > > This of course assumes some small glitches are allowed like the overhead of > copying a string/list, because the gc can free that memory at once if needed. > > For simple scripts, e.g. the ugly 100s of 'resizer' scripts you find in > hairs, shoes etc. this could work pretty well, as those are usually just one > link_message handler with trivial code and one or two functions that call > llSetPrimitiveParams(). You might overestimate by one or two kB, because you > don't know how big the link_message string and key parameters are, but other > than that it should work pretty well. > > Michael > >> >> On Mon, Mar 8, 2010 at 2:03 PM, Michael Schlenker >> wrote: >>> >>> Am 08.03.2010 um 18:46 schrieb Kelly Linden: >>> >>>> We are not out to write a new malloc for mono. What we have is a system >>>> that throws an exception when the memory used by the script hits a certain >>>> threshold (64k currently). This exception is caught so we can "crash" the >>>> script. The future small scripts and big scripts projects will add new >>>> functions to set and get this threshold value, allowing scripters to >>>> effectively control how much memory is reserved for their script. We will >>>> continue to use mono's default memory management within the reserved >>>> memory thresholds. It is a much simpler problem to solve. >>>> >>> While your at it, how about a static analyzer for mono/LSL that determines >>> guaranteed lowest memory consumption for a script and sets the threshold >>> there. >>> >>> That would have the benefit of easing scripters work by providing useful >>> defaults for all the easy cases without them having to do anything at all. >>> >>> The scheme should only break down if the mono GC behaves weird. In that >>> case scripters have a huge problem anyway as they cannot set any threshold >>> without being crashed at random by a lazy GC. >>> >>> Michael >>> ___ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> > > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] [server-beta] Script Memory ManagementAlgorithm
There's a semantic issue here that we need to clear up. When we say how much memory a script is "actually using", that means the amount of memory the script is making semantic usage of. However, the script is *allocated* a larger amount. This larger amount is the amount that matters to the system: it's the *cost* of the script, and what needs to be controlled. If someone is wearing scripts that are allocated 1MB of space, it doesn't lower the impact on the sim that the scripts happen to be making effective use of only a small fraction. That memory is still reserved for the script and can't be used by anything else, and contributes to thrashing when overallocated. The metrics need to show the *burden* the scripts are placing on the system. It doesn't help to see that they're using that burden inefficiently and give the wearer a break on that basis. In other words, It's the cost that counts, not the benefit. Lear On Tue, Mar 9, 2010 at 1:29 PM, Kitty wrote: >> It might be possible to add display of memory currently used >> as well, but what's the use case for it? > > It would allow residents to independently review the imposed script limits. > > Another use case would be because people *are* going to start banning > residents based on what the script limits UI says (just like people are > ejected/banned over ARC). If some random resident hasn't spent hours and > hours trying to see if everything they've bought in the past few years > doesn't have an update for it that uses the upcoming "llReserveMemory" they > will end up banned from random places for wearing the wrong item. > > Simply reporting "actually in use" for *other* residents even though the > individual limit is against a "hypothetical maximum limit" would do a whole > lot to help with that. A Mono script would still count as 64Kb against that > avie's personal limit, but anyone else trying to look for information would > be seeing say 8Kb because that's how much it's actually using and actual > usage is really the only thing parcel and sim owners are (or should) care > about when it comes to other people's attachments. > >> Likewise, it would be useful for verifying sellers' signs' >> claims immediately after purchase, should a scripted object >> be displayed as a static, unscripted object. The ability to >> see the number of prims in a linked set helps similarly for >> advertised prim counts. > > It likely won't take very long for the sellers of scripted gadgets to > include "script usage" information, but it will be many months before > someone selling - for example - earrings with a texture change script is > going to do the same or before they even find out that there is such a thing > as script limits. > > The examples of "troublesome" cases that require script limits in the first > place never seem to be the highly technical kind, but rather the every day > "mundane" things like hair, shoes, jewelry, prim skirts, etc. So the people > who are least likely to include that information, or even know that > something like script limits exists. > > I already have literally hundreds of "script-in-every prim" things I've > bought - where I can't even delete the scripts because of a change to "no > modify" some time back - that might just be good for relocating to the trash > 6 months from now. Moving forward, noone should find out *after* purchase > whether or not what they just bought is something they'll be able to wear, > or whether they'll see the dreaded "Not enough script resources available to > attach object!" and know that they just threw money out the window. > > When someone picks "Buy", the script limit/usage for each individual object > inside of the prim should really just be right there alongside the > permissions the item will have. > Use of green/yellow/red from ARC would make things even simpler still for > the average resident: anything using less than 1/38th of the per-avatar > limit (limit divded by # possible attachments) shows green, several > multiples is yellow and anything more is red. > > Kitty > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Script Memory Management Algorithm
If it were a simple change, I'm sure it would be considered. What
you're suggesting sounds like would require a massive rewrite. I
agree that a dynamic system would be much better, easier to code and
less wasted memory. But without detailed knowledge of how the system
is currently implemented, it's not possible to assess how difficult it
would be to change from a fixed allocation scheme to a dynamic one.
It's easy to ask for changes without regard to the cost. LL needs to
consider the cost, in terms of effort and risk. Can you do a
cost/benefit analysis on your suggestion? Or are you just being
immovably stubborn?
Lear
On Tue, Mar 9, 2010 at 8:26 AM, Carlo Wood wrote:
> This is exactly the kind of reaction that drives me away from here.
>
> I propose a simple way get FOUR times the memory for all the scripts, at
> no other cost than adding some malloc code to your mono engine.
>
> And you simply say, "This is what we ARE doing, we're not going to change
> that".
>
> Why this immovable stubbornness about internal development decisions?
>
> In case with the below you mean to say "allowing people to set ammount
> of memory at which their scripts crash, up front, is as good," then
> read the past posts on this list again.
>
> People say that it is NOT, by FAR not, as good. Scripters shouldn't
> have to manually figure out the maximum ammount of memory their scripts
> can possibly use and use that as the fixed ammount of memory that
> their script reserves. That was last done 10 years ago. Just have the
> server take care of this: give a script a minimum, and when it needs
> more, give it more. No hassle for the users.
>
> On Mon, Mar 08, 2010 at 09:46:44AM -0800, Kelly Linden wrote:
>> We are not out to write a new malloc for mono. What we have is a system that
>> throws an exception when the memory used by the script hits a certain
>> threshold
>> (64k currently). This exception is caught so we can "crash" the script. The
>> future small scripts and big scripts projects will add new functions to set
>> and
>> get this threshold value, allowing scripters to effectively control how much
>> memory is reserved for their script. We will continue to use mono's default
>> memory management within the reserved memory thresholds. It is a much
>> simpler
>> problem to solve.
>>
>> - Kelly
>>
>> On Sun, Mar 7, 2010 at 5:50 AM, Carlo Wood wrote:
>>
>> Lets assume that the *average* script uses
>> 8 to 16 kB of real memory. LL's design allocates
>> 64 kB regardless, leading to an overhead of
>> 400 to 800% (meaning they need to buy 5 to
>> 9 times the memory that is theoretically needed).
>>
>> In that light, I gave it some more thought, and
>> think something as complex as my rmalloc's algorithm,
>> with it's 19% overhead, isn't needed (note that
>> it's both faster than gmalloc as well as three
>> times more efficient; so complexity is not always
>> a bad thing ;).
>>
>> Nevertheless, in this case, since the scripts
>> use a maximum of 64 kB, you can use the
>> following design:
>>
>> Let each allocated block be a power of 2
>> kilobytes, with a maximum of 64 kB (and a
>> minimum of 1 KB, or 4 if even the tiniest
>> script needs that).
>>
>> It is easy to see that this would lead
>> to an overhead of 25% on average per
>> allocated block.
>>
>> We'd still have to deal with "holes" of a
>> full 64 kB where blocks became totally
>> unused, but normally scripts in objects are
>> started all at once when a sim reboots, and
>> only seldom stopped. The scripts that will
>> most likely attribute to random starting
>> and stopping of scripts will be the scripts
>> in attachments. A worst case scenario would
>> be one where there are 50 avies in a sim
>> (during a meeting), then a new avie enters
>> with some scripts which need to be allocated
>> at the top of the heap; then the previous
>> 50 avies leave. That would create a hole
>> in the heap of the size of all the scripts
>> of those 50 avies. If script memory would
>> be relocatable, then this problem doesn't
>> exist of course. I can't simply estimate
>> the average overhead caused by this, but
>> because the algorithm described here is
>> basically the one used by gmalloc (which
>> in my test used 62% overhead) I'm pretty
>> sure that it will be less than -say- 100%
>> overhead; still 4 to 8 times more efficient
>> than the current design on the table.
>>
>> The API for this design would be something
>> like the following:
>>
>> namespace script_memory_management {
>>
>> void* ll_sbrk(ptrdiff_t); // Increment the size of the heap
>> int ll_brk(void*); // Set the size of the heap explicitely
>>
>> void* ll_malloc64(void); // Get a new 64 kB block.
>> void ll_free64(void*); // Free such a block.
>>
>> void* ll_
Re: [opensource-dev] [server-beta] Script Memory ManagementAlgorithm
Which is what we mean by "cost". Price is what you are asked to pay. Cost is what you actually pay. Thus the phrase "cost/benefit analysis" -- not "price/benefit analysis". On Wed, Mar 10, 2010 at 11:46 AM, Maggie Leber (sl: Maggie Darwin) wrote: > On Wed, Mar 10, 2010 at 11:43 AM, Lear Cale wrote: > >> When we say how much memory a script is "actually using", that means >> the amount of memory the script is making semantic usage of. However, >> the script is *allocated* a larger amount. This larger amount is the >> amount that matters to the system: it's the *cost* of the script, and >> what needs to be controlled. > > It might be more accurate to say it's the *price*, not the *cost*, > since it is what you will be charged for regardless of how much you > actually *use*. > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Script memory limit vs server CPU utilization as a key metric
On Thu, Mar 11, 2010 at 7:18 AM, Carlo Wood wrote: > On Wed, Mar 10, 2010 at 03:51:31AM -0800, Ann Otoole wrote: >> If you guys want to really help then give us the ability to disable scripts >> by >> attachment creator name. There are certain products that cause problems. Made >> by people LL props up as shining examples of how creators should be BTW lmao. This would be a really bad idea, because there are plenty of full-perm freebies from reputable, sensible content creators that anyone could easily turn into a resource hogs, sullying those creators' names. This would be an easy way to torpedo a competitor. I vote a resounding "no". Instead, we need the ability to delete scripts from objects even if they're no-mod, as we used to have. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] [server-beta] Script Memory Management Algorithm
I disagree, Argent. If the server process does explicit swapping for script memory, it would have a dramatically lower impact on the server process as a whole, and no impact on the other server processes sharing the same machine. > It doesn't matter whether the swapping is done by the OS or by the > server process, it's the disk I/O bottleneck that swapping causes > that's the real problem. If the complexity is manageable, this would be a good solution. However, it's nearly impossible for those of us who don't know the internals of Mono or it's SL adaptation to assess the complexity that this would require. We all know that in practice, even when we understand a system quite thoroughly, making an underlying change that seems easily uncoupled turns out to be surprisingly trickier than we'd thought. Reminds me of a famous statement often made by gurus: "Sure, try it, it should just work!" Sometimes, they're right! Lear On Thu, Mar 11, 2010 at 7:33 AM, Argent Stonecutter wrote: > On 2010-03-11, at 06:21, Jonathan Irvin wrote: >> Maybe we can handle scripts like Linux handles memory. Use up an >> allotted space based on requirements and if it exceeds that (among >> other scripts using the same shared environment) it can begin to >> swap in it's own little cluster. > > It doesn't matter whether the swapping is done by the OS or by the > server process, it's the disk I/O bottleneck that swapping causes > that's the real problem. > > And making scripts run on a separate server would just make all > scripts many times slower and increase server network overhead. > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Script Memory Management Algorithm
Fine, don't waste your time responding. Go do better things. On Thu, Mar 11, 2010 at 6:39 AM, Carlo Wood wrote: > It makes little sense to me to put time into convincing a random non-Linden. > And since LL is going to ignore the whole discussion/idea anyway, I have > better things to do. Sorry. > > On Wed, Mar 10, 2010 at 11:56:36AM -0500, Lear Cale wrote: >> If it were a simple change, I'm sure it would be considered. What >> you're suggesting sounds like would require a massive rewrite. I >> agree that a dynamic system would be much better, easier to code and >> less wasted memory. But without detailed knowledge of how the system >> is currently implemented, it's not possible to assess how difficult it >> would be to change from a fixed allocation scheme to a dynamic one. >> >> It's easy to ask for changes without regard to the cost. LL needs to >> consider the cost, in terms of effort and risk. Can you do a >> cost/benefit analysis on your suggestion? Or are you just being >> immovably stubborn? > > There would be a one-time cost to write it. I doubt that needed > four to eight times the amount of physical RAM weight up against > any (possible) maintenance cost (which I estimate to be neglectable > in the first place). > >> Lear > > -- > Carlo Wood > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] [server-beta] Script Memory Management Algorithm
The intent isn't to try to exceed or even come close to hardware-based virtual memory. The intent is to isolate the effects of memory overuse of one part of the system, to keep this from affecting other parts. However, I'd wager that you're right that it would involve a noteworthy performance penalty, even when no paging is required. Lear On Thu, Mar 11, 2010 at 8:56 AM, Argent Stonecutter wrote: > On 2010-03-11, at 07:48, Lear Cale wrote: >> I disagree, Argent. If the server process does explicit swapping for >> script memory, it would have a dramatically lower impact on the server >> process as a whole, and no impact on the other server processes >> sharing the same machine. > > Decades of experience with the results of programs trying to beat the > performance of demand paged virtual memory with manual ad-hoc paging > systems makes me remarkably skeptical of this claim. > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Request for comments about llSetAgentEnvironment / SVC-5520
I agree. WL settings are about the appearance of the environment, not the GUI per se. And Carlo has a great suggestion that WL settings should be supported as inventory items, similar to LMs. (Going to make a JIRA for that, Carlo?) On Fri, Mar 12, 2010 at 8:27 AM, Carlo Wood wrote: > On Wed, Mar 10, 2010 at 09:42:27AM -0800, Kelly Linden wrote: >> I admit I only briefly skimmed the jira. I was mostly reacting to the panic >> I >> saw here. I don't think it needs a permission request in the case of parcel >> owners, but that is just my personal opinion. I do believe the environment >> should be promoted to being part of the content and not part of the viewer, I >> think we get more amazing in world experiences that way. > > +1 > > WindLight settings should have made a shared experiece a long > long long time ago. For years people have been complaining about > delivering half-work, about not finishing it! > > It is no different than whether the region default is midday, > sunrise, sunset or midnight (or anything in between). > > A *shared experience* is an important part of Second Life, > it is even mentioned in the TPV policy as being of major > importance, something I whole heartedly agree with! > > To me, it is crucial to know that my friends, when we are > exploring, see the same thing as me, so that we can react to > it and weave a story around our collective experience, without > that I have to ask: what is your draw distance? what is your > environment setting? :( > > Hence, all windlight settings should at LEAST be part of the > region default and be set the moment you enter, without popups > or permission request by default. > > I suppose that some people do NOT want a shared experience > and to live in their own little isolated world. Well, can't > deny them power over their own viewer, so there should be > an opt-in to ignore windlight settings (and keep the current > one). But may I remind you that there is ALSO no opt-in to > ignore the music url of a parcel, and keep the one you have > set? > > More important questions are these: > > * Who can change the windlight settings? > * Should there we windlight settings per estate only, or > per parcel as well? > > And things that I would like personally are things > that promote sharing windlight settings: > > * Allow windlight settings to be 'traded' like objects. > > It should be possible for ANYONE to create their own > windlight setting (that only they see at that moment) > and then "hand that over" to friends, or to the estate > owner, or to a parcel owner, or just keep a collection > of them to play with. > > -- > Carlo Wood > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Request for comments about llSetAgentEnvironment / SVC-5520
I think we're arguing over something that's a side effect of an implementation decision, not a fundamental issue of personal liberty. Windlight happens to be client side rather than server-side, even though it's more about the environment -- the created world -- than it is about personal control of the GUI's look and feel. In any case, a lot of people will want to retain control and should be able to. I suggest that, for parcel or region control, the first time an automatically-grantable request to change WL happens, the user should see a popup which asks whether to allow it, along with a "don't ask again" checkbox. This popup would be in the form of a GUI popup rather than the permission popup. The permission popup would only be for cases where permission isn't automatically grantable. (The script would think it got permission, and this should be DOCUMENTED so it doesn't get reported as a bug.) This should satisfy most people on both sides of this fence. Most people would grant it and never worry again. Those who don't want to yield control would only have to click "no" once. And it would be a checkbox in the "View" menu somewhere, to change on a whim. Lear On Fri, Mar 12, 2010 at 9:56 AM, Maggie Leber (sl: Maggie Darwin) wrote: > On Fri, Mar 12, 2010 at 8:27 AM, Carlo Wood wrote: > >> I suppose that some people do NOT want a shared experience >> and to live in their own little isolated world. Well, can't >> deny them power over their own viewer, > > Good, thank you. Because there are people who don't seem to believe in > that; that owning some parcel should give them huge rights to control > other people's viewers. > >> But may I remind you that there is ALSO no opt-in to >> ignore the music url of a parcel, and keep the one you have >> set? > > Actually *loading* the music URL *IS* an opt in, thank goodness, in > the current production viewer (and the current beta viewer behavior of > automatically willy-nilly loading of URLs is a *huge* security issue) > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Request for comments about llSetAgentEnvironment / SVC-5520
Oops, clarification. The script would think it got permission in the case where it's automatically granted, but denied by the GUI popup. In the case where permission isn't automatic, the user gets the popup and the script gets permissions only if the answer is affirmative. On Fri, Mar 12, 2010 at 10:33 AM, Lear Cale wrote: > I think we're arguing over something that's a side effect of an > implementation decision, not a fundamental issue of personal liberty. > Windlight happens to be client side rather than server-side, even > though it's more about the environment -- the created world -- than it > is about personal control of the GUI's look and feel. > > In any case, a lot of people will want to retain control and should be able > to. > > I suggest that, for parcel or region control, the first time an > automatically-grantable request to change WL happens, the user should > see a popup which asks whether to allow it, along with a "don't ask > again" checkbox. This popup would be in the form of a GUI popup > rather than the permission popup. The permission popup would only be > for cases where permission isn't automatically grantable. (The script > would think it got permission, and this should be DOCUMENTED so it > doesn't get reported as a bug.) > > This should satisfy most people on both sides of this fence. Most > people would grant it and never worry again. Those who don't want to > yield control would only have to click "no" once. And it would be a > checkbox in the "View" menu somewhere, to change on a whim. > > Lear > > On Fri, Mar 12, 2010 at 9:56 AM, Maggie Leber (sl: Maggie Darwin) > wrote: >> On Fri, Mar 12, 2010 at 8:27 AM, Carlo Wood wrote: >> >>> I suppose that some people do NOT want a shared experience >>> and to live in their own little isolated world. Well, can't >>> deny them power over their own viewer, >> >> Good, thank you. Because there are people who don't seem to believe in >> that; that owning some parcel should give them huge rights to control >> other people's viewers. >> >>> But may I remind you that there is ALSO no opt-in to >>> ignore the music url of a parcel, and keep the one you have >>> set? >> >> Actually *loading* the music URL *IS* an opt in, thank goodness, in >> the current production viewer (and the current beta viewer behavior of >> automatically willy-nilly loading of URLs is a *huge* security issue) >> ___ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New TOS - Compulsory patent licensing gone?
This was never prohibited by the old patent clause, which applied only to the patent holder's content. On Thu, Apr 1, 2010 at 2:05 AM, Jonathan Bishop wrote: >> The new TOS does not include a section on compulsory patent licensing. >> I hope that this omission was unintended and will be rectified, as >> software patents are a particular danger to open source developers. > > > Actually, it is more serious than the open source developers...and way more > problematic than the complex and subtle interplay of the TOS and the TPVP. > Without the "patent peace" clause it is possible for people to apply to > patent content in SL. Which means scripts and combinations of objects and > methods. > > > This is potentially disastrous for SL creators and LL as their world could > be wrapped up in patents that prevent the creation of new content. We could > look forward to patents on "a method to simulate wearable realworld skirts > using attached textured prims" - the prim skirt, and "a method to conduct > meetings in virtual worlds among remote attendees" - the meeting room. > > And, of course none of the content would be of sufficient value to justify > filing a defense over. > > Regards > > Jonathan Bishop > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New TOS - Compulsory patent licensing gone?
The previous patent clause did not do what you claim it did. On Thu, Apr 1, 2010 at 11:58 AM, Jonathan Bishop wrote: > > Simon Disk: > > > Could be wrong but I read the new ToS as lumping patent rights under > Intellectual Property Rights and then compelling the user to grant a license > under IPR (and therefore also patent rights)… > > > > Yes. I agree. That seems to be the case. S4.1, S7.1, and S7.2, however > don’t seem to do what the previous patent peace clause did however. This > one entitles LL to deal with the IP, but it does not extinguish the right > for an creator to assert patent rights over content with respect to the > created content of other creators, so it does not seem to go as far in > ensuring patent peace as the previous TOS. In fact by grouping patents with > copyright and trademarks under IP it looks to me like it might have the > opposite effect – to actively endorse the establishment and assertion of > such rights with respect to patents. > > > > I wonder if this was intended. There are strong arguments on both sides of > the view, but given Ginsu Linden’s (Linden Lawyer) previous strong > pronouncements against patents in software generally and specifically in the > context of user generated content in SL, a TOS that appears to omit the more > encompassing patent peace clause is surprising. > > > > No doubt there is a reason for it, but I can’t see the intrusion of patent > protection into SL content as beneficial for innovation and advancement of > the VW concept at this early stage in the game. > > > > > > Regards > > > > *Jonathan Bishop** > **Managing Director* > > * * > > ** > > *Bishop Phillips Consulting* | Melbourne, Australia – Vancouver, Canada > Mobile +61 411.404.483 | Office +61 (3) 9525.7066 | Fax +61 (3) 9525.6080 > bish...@bishopphillips.com | www.bishopphillips.com** > > * * > > > > > -- > > *From:* opensource-dev-boun...@lists.secondlife.com [mailto: > opensource-dev-boun...@lists.secondlife.com] *On Behalf Of *Simon Disk > *Sent:* Thursday, 1 April 2010 11:48 PM > *To:* opensource-dev@lists.secondlife.com > *Subject:* Re: [opensource-dev] New TOS - Compulsory patent licensing > gone? > > > > Could be wrong but I read the new ToS as lumping patent rights under > Intelectual Property Rights and then compelling the user to grant a license > under IPR (and therefore also patent rights). > > > > Under section 4.1 it defines IPR as: > > > > "Intellectual Property Rights" means copyrights, trademarks, service marks, > trade dress, publicity rights, database rights, *patent rights*, and other > intellectual property rights or proprietary rights recognized by law. > > > > Then under section 7.1: > > > > You retain any and all *Intellectual Property Rights* you already hold > under applicable law in Content you upload, publish, and submit to or > through the Servers, Websites, and other areas of the Service, subject to > the rights, licenses, and other terms of this Agreement, including any > underlying rights of other users or Linden Lab in Content that you may use > or modify. > > > > Then under 7.2: > > > > You agree that by uploading, publishing, or submitting any Content to or > through the Servers, Websites, or other areas of the Service, you hereby > automatically grant Linden Lab a non-exclusive, worldwide, royalty-free, > sublicenseable, and transferable license to use, reproduce, distribute, > prepare derivative works of, display, and perform the Content solely for the > purposes of providing and promoting the Service. > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New TOS - Compulsory patent licensing gone?
Oops, never mind -- yes it did. My mistake. On Thu, Apr 1, 2010 at 12:33 PM, Lear Cale wrote: > The previous patent clause did not do what you claim it did. > > On Thu, Apr 1, 2010 at 11:58 AM, Jonathan Bishop < > bish...@bishopphillips.com> wrote: > >>> Simon Disk: >> >> > Could be wrong but I read the new ToS as lumping patent rights under >> Intellectual Property Rights and then compelling the user to grant a license >> under IPR (and therefore also patent rights)… >> >> >> >> Yes. I agree. That seems to be the case. S4.1, S7.1, and S7.2, however >> don’t seem to do what the previous patent peace clause did however. This >> one entitles LL to deal with the IP, but it does not extinguish the right >> for an creator to assert patent rights over content with respect to the >> created content of other creators, so it does not seem to go as far in >> ensuring patent peace as the previous TOS. In fact by grouping patents with >> copyright and trademarks under IP it looks to me like it might have the >> opposite effect – to actively endorse the establishment and assertion of >> such rights with respect to patents. >> >> >> >> I wonder if this was intended. There are strong arguments on both sides >> of the view, but given Ginsu Linden’s (Linden Lawyer) previous strong >> pronouncements against patents in software generally and specifically in the >> context of user generated content in SL, a TOS that appears to omit the more >> encompassing patent peace clause is surprising. >> >> >> >> No doubt there is a reason for it, but I can’t see the intrusion of patent >> protection into SL content as beneficial for innovation and advancement of >> the VW concept at this early stage in the game. >> >> >> >> >> >> Regards >> >> >> >> *Jonathan Bishop** >> **Managing Director* >> >> * * >> >> ** >> >> *Bishop Phillips Consulting* | Melbourne, Australia – Vancouver, Canada >> Mobile +61 411.404.483 | Office +61 (3) 9525.7066 | Fax +61 (3) 9525.6080 >> bish...@bishopphillips.com | www.bishopphillips.com** >> >> * * >> >> >> >> >> -- >> >> *From:* opensource-dev-boun...@lists.secondlife.com [mailto: >> opensource-dev-boun...@lists.secondlife.com] *On Behalf Of *Simon Disk >> *Sent:* Thursday, 1 April 2010 11:48 PM >> *To:* opensource-dev@lists.secondlife.com >> *Subject:* Re: [opensource-dev] New TOS - Compulsory patent licensing >> gone? >> >> >> >> Could be wrong but I read the new ToS as lumping patent rights under >> Intelectual Property Rights and then compelling the user to grant a license >> under IPR (and therefore also patent rights). >> >> >> >> Under section 4.1 it defines IPR as: >> >> >> >> "Intellectual Property Rights" means copyrights, trademarks, service >> marks, trade dress, publicity rights, database rights, *patent rights*, >> and other intellectual property rights or proprietary rights recognized by >> law. >> >> >> >> Then under section 7.1: >> >> >> >> You retain any and all *Intellectual Property Rights* you already hold >> under applicable law in Content you upload, publish, and submit to or >> through the Servers, Websites, and other areas of the Service, subject to >> the rights, licenses, and other terms of this Agreement, including any >> underlying rights of other users or Linden Lab in Content that you may use >> or modify. >> >> >> >> Then under 7.2: >> >> >> >> You agree that by uploading, publishing, or submitting any Content to or >> through the Servers, Websites, or other areas of the Service, you hereby >> automatically grant Linden Lab a non-exclusive, worldwide, royalty-free, >> sublicenseable, and transferable license to use, reproduce, distribute, >> prepare derivative works of, display, and perform the Content solely for the >> purposes of providing and promoting the Service. >> >> ___ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Soft body physics
I agree with Jacek -- at least for 1st cut, make it so that flexi hair doesn't pierce anyone's body, but no effect on collisions. This would keep it simple and fix the biggest issue for most people. On Wed, Apr 7, 2010 at 7:39 PM, Jacek Antonelli wrote: > Personally, I would keep soft body effects as purely client-side eye > candy, without any impact on the world, like flexi prims and particles > are today. Sending the deformation data from the server to the client, > or vice versa, would be very bandwidth intensive, and a huge headache > to keep in sync. And some users would need to disable the feature > altogether, because it would also be costly to process the effect. > > - Jacek > > On Wed, Apr 7, 2010 at 2:48 PM, Glen Canaday wrote: >> I came to the same conclusion, with the exception that a lookahead for a >> collision would be helpful in the client. If they use the same physics >> engine and the client does no more than implement a collision check, I think >> it could be a good thing. I'm looking at several free physics engines atm >> and thought I would clear my thinking up some. Collisions with soft bodies >> deform the collision mesh itself so yeah it gets a little tricky when you >> split them. >> >> --GC >> >> On 04/07/2010 11:14 AM, Moriz Gupte wrote: >> >> I feel you are right. Makes more sense to have it implemented client side >> for many soft body dynamic behaviors... eg cloth, hair etc... >> but I think in areas where rigid body behaviors impact local soft body >> dynamics, there will be lots of timing and synch problems to deal with. >> So there's where I think that perhaps all physics need to be done at the >> same site. >> R >> >> On Wed, Apr 7, 2010 at 9:03 AM, Glen Canaday wrote: >>> >>> >>> Soft body physics are best implemented in a local viewer, leaving the >>> rigid-body collision detection to the server, am I right in this? >>> >>> --GC >>> ___ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >> >> >> >> -- >> 'Consider how the lilies grow. They do not labor or spin.' >> Rameshsharma Ramloll PhD Research Assistant Professor Idaho State >> University, PocatelloTel: 208-282-5333 >> More info at http://tr.im/RRamloll >> >> >> >> ___ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] impending lawsuit?
FYI, Whoever wrote this is ignorant of US copyright and trademark law. In the US (and most countries), you have an implicit copyright whenver you render an original work in any fixed medium. I.e., if you sing a song you made up, no implicit copyright, but if you record it or write it down, you do get one. "Work" here means "work of an author". A copyright does not have to be registered to be valid. It does have to be registered to file suit; failure to register before publication means you can still collect damages but not "statutory damages and attorneys' fees". If subsequent posts are correct for what this is about, copyrights don't apply anyway. Also, you can't copyright a name. You use trademarks to protect a name. So just be warned that there's a lot of bullshit going on here, on both sides of the fence. IANAL but I do know a little about copyright law. You can verify these facts at http://www.copyright.gov . Jeff On Wed, Apr 14, 2010 at 4:28 AM, Lance Corrimal wrote: > Hey all, > > just got this notecard inworld: > > "Hello. > > You are reading this because you were listed in a lawsuit by Belial Foulsbane > and Scarlett Vielle. > Somehow you are a victim of his False DMCA claims, and his ongoing effort to > manipulate LL into killing off his competition for the "Emerald Speed Rez". > > If you would like to join the defendants against this paperwork-greifer in a > counter lawsuit please contact me with your SL name and anything else at > prime...@gmail.com > > Do not be scared > 1) Scarlett Vielle claimed that they automaticly had a protected copyright > from the moment they made anything. > (The US copyright office is not aware of every creation in SL, does not issue > free copyrights, and does not issue anything without a proper filing) > > 2) There is no copyright registered in the united states: > http://cocatalog.loc.gov/cgi-bin/Pwebrecon.cgi?DB=local&PAGE=First > > 3) Linden Labs cannot be sued. Yet he filed against them. > > 4) The judges signature on his legal papers he faxed to LL is blank. > > 5) He cannot copyright the word "Emerald" for the same reason he cannot > copyright the word "SecondLife" or "Microsoft". > > He is a paperwork bully filing false DMCA claims as you know. > > If you have any ideas to stop this madman, do please share them. > Lets create a group and fight him off shall we? > > zFire" > > > ... is that guy out of his mind? > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] impending lawsuit?
Another point: A copyright means you can't copy the work. You are allowed to come up with the same idea yourself and arrive at a simiar result. It requires a patent to protect against that. Furthermore, DMCA applies only when the original work is *digitally* copied. It does *NOT* apply to a forger painting a duplicate of someone else's work. That falls under normal copyright law. If you didn't bypass copyright protection mechanisms to duplicate the original, it's not a DMCA violation. LL may use received DMCA filings for purposes other than the intent of DMCA, though -- that's their issue. On Wed, Apr 14, 2010 at 11:46 AM, Lear Cale wrote: > FYI, Whoever wrote this is ignorant of US copyright and trademark law. > In the US (and most countries), you have an implicit copyright > whenver you render an original work in any fixed medium. I.e., if you > sing a song you made up, no implicit copyright, but if you record it > or write it down, you do get one. "Work" here means "work of an > author". > > A copyright does not have to be registered to be valid. It does have > to be registered to file suit; failure to register before publication > means you can still collect damages but not "statutory damages and > attorneys' fees". > > If subsequent posts are correct for what this is about, copyrights > don't apply anyway. > > Also, you can't copyright a name. You use trademarks to protect a name. > > So just be warned that there's a lot of bullshit going on here, on > both sides of the fence. > > IANAL but I do know a little about copyright law. You can verify > these facts at http://www.copyright.gov . > > Jeff > > On Wed, Apr 14, 2010 at 4:28 AM, Lance Corrimal > wrote: >> Hey all, >> >> just got this notecard inworld: >> >> "Hello. >> >> You are reading this because you were listed in a lawsuit by Belial Foulsbane >> and Scarlett Vielle. >> Somehow you are a victim of his False DMCA claims, and his ongoing effort to >> manipulate LL into killing off his competition for the "Emerald Speed Rez". >> >> If you would like to join the defendants against this paperwork-greifer in a >> counter lawsuit please contact me with your SL name and anything else at >> prime...@gmail.com >> >> Do not be scared >> 1) Scarlett Vielle claimed that they automaticly had a protected copyright >> from the moment they made anything. >> (The US copyright office is not aware of every creation in SL, does not issue >> free copyrights, and does not issue anything without a proper filing) >> >> 2) There is no copyright registered in the united states: >> http://cocatalog.loc.gov/cgi-bin/Pwebrecon.cgi?DB=local&PAGE=First >> >> 3) Linden Labs cannot be sued. Yet he filed against them. >> >> 4) The judges signature on his legal papers he faxed to LL is blank. >> >> 5) He cannot copyright the word "Emerald" for the same reason he cannot >> copyright the word "SecondLife" or "Microsoft". >> >> He is a paperwork bully filing false DMCA claims as you know. >> >> If you have any ideas to stop this madman, do please share them. >> Lets create a group and fight him off shall we? >> >> zFire" >> >> >> ... is that guy out of his mind? >> >> ___ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
