[sldev] Script/Parcel/Memory Limits - Memory Limit Configuration
Imaze Rhiano
imaze.rhiano at gmail.com
Sat Dec 19 05:24:19 PST 2009
I fully agree with Kelly here.
People are buying their parcel to get certain guaranteed amount of
primitives and space from virtual world for their use. Same way people
want to get certain guaranteed amount of memory for their scripts for
their use. They don't want their landlord comes to say that they can use
that swimming pool for their activity - but they need to share it with
sexists neighbors. No - they want their own private swimming pool.
Other fact is that people are stupid. Fixed memory limits would be most
easily understood by average Joe and Jane. They really don't want to use
their head to calculate how many scripts they can deploy to their parcel
before hitting to boundaries. Keep it simple and stupid.
However - same time - they should be some configuration available.
Landlords should be either able to decide memory limits for each parcel
- or - use similar system that allows current double primitive parcels.
If this kind configuration is not available- then we will quickly see
how landlord convert their current double primitive estates to normal
primitive estates and remove all streets and other "community" parcels
from their estates.
... and I agree with bloooo kitty that fixed memory limits are not
scalable solution - however - Scripted Life (tm) architecture is not
scalable anyway - so who cares? :P
Kelly Linden kirjoitti:
> Ooooh! I love the completely ridiculous analogy game! Can I play?
>
> Carlo manages an apartment complex. After renting apartments for
> years out to just single families he realizes that significant
> portions of his building are empty and not being used for significant
> periods of the day. He can make more money by renting to more people
> if he can fill up that space. Given holidays, work, school, errands,
> entertainment etc each family is probably only in their space for 50%
> of the time. Heck if you consider it on a per room basis and take
> into account sleeping time, there is even more unused space! So he
> rents each apartment out to 3 families, which should totally be fine
> and he continues to charge and allocate the space as if each family
> had their own apartment. After all there are enough rooms for
> everyone, for the portion of the time they are probably home.
>
> Of *course* this is ridiculous, and of *course* the swimming pool
> example is ridiculous and of *course* the SL resource problem doesn't
> directly map to either. Though I think it may be closer to the
> apartment case than the swimming pool example. When you rent or lease
> land you aren't buying entrance to a theme park or movie or swimming
> pool. You are buying space to live or work or whatever. You want to
> know that your TV will work whenever you want to use it and that your
> bed will be available to you. The pool owner wants to know that his
> electricity and pool filtering and water supply aren't tied to factors
> he can't control, and he wants to know that he can support 30 swimmers
> whether the club across the street is open or not.
>
> However as I have said before I don't think strict allocation of
> available resources make sense either, because SL isn't an apartment
> building or a swimming pool. In that very post you replied to I
> talked about overselling and managing the hosts regions run on to keep
> regions happy. This I think is a reasonable compromise that allows
> for a simple to understand system that is easy to work with and plan
> with but doesn't overly sacrifice available resources.
>
> - Kelly
>
> On Fri, Dec 18, 2009 at 3:55 PM, Carlo Wood <carlo at alinoe.com
> <mailto:carlo at alinoe.com>> wrote:
>
> On Fri, Dec 18, 2009 at 10:13:36AM -0800, Kelly Linden wrote:
> > I place a high value on simplicity. I want to trivially
> understand where I am,
> > how much headroom I have, how close I am to what limits there
> are. I don't
>
> The swimming pool
> -----------------
>
> Once upon a time there was a swimming pool that costed $100 per day
> to run. Every day 100 people came to swim. Of course, they didn't
> come all at the same time, thank God no! Imagine that... you'd only
> have 1/100th of the water to swim in! No, sometimes there were
> a little more and sometimes there were a little less people.
> Not everyone stayed 24 hours per day, after all.
>
> One day, one of the customers complained to the management of
> the swimming pool, saying "Last Wednesday I could swim in my
> own lane, but today it's way too crowded to swim! I wish I could
> see how many people are inside before I pay the entrance fee!"
> and he looked really mad.
>
> Now the manager, Mr.Kelly, was a smart man and he found quickly
> a solution that everyone would understand, and after which everyone
> would have precisely the same area to swim in no matter when they
> would come! He said: Although there come 100 people every day,
> I think that at the most busy moments of the say I've ever
> only seen 30 at the same time. That number might be changed a bit,
> but lets say that's the maximum. Then we can garantee that you
> have the same area to swim in at every moment by giving you
> 1/30 of the swimming pool. From now on, even if the pool is
> EMPTY... or when there are only 3 people like on Sunday mornings,
> you are not allowed to use more than 1/30 of the swimming pool
> area. This way we have solved the problem of those griefer
> school kids too that come here with 100 kids at once, just to
> obstruct and annoy the other swimmers: as soon as there are
> really 30 people inside, we close the doors :).
>
> And so, everyone was happy-- because now they knew that whenever
> they came, they would have precisely 1/30 of the swimming pool...
> Well, except for about 90% of the customers, who were used to
> having MUCH more space normally, but they were quickly convinced
> that they only PAID for 1/30 (after all the math was such that
> nobody could argue here). And yeah, the entrence price remained
> the same too. One year later the swimming pool was broke.
>
> The End
>
> --
> Carlo Wood <carlo at alinoe.com <mailto:carlo at alinoe.com>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
More information about the SLDev
mailing list