land scanners part the fourth

I am wondering how island sim owners would feel about these scanners over their sims.....

You can't release Island land, so there will never be any public land to scan for!

One out of one island owner isn't pleased. Which, as Eggy sagely pointed out, if these were mere land scanners, putting them on islands would either be a) useless and/or b) ornery.

Earlier in this bout of controversy I was asked by an island owner to scan for the viral "lb v2" objects on the island sim. I did a quick scan at known locations and said "negative". I feel I owe a more concerted look.

Best of all, as temp-on-rez objects can't self teleport to island sims, so the virus creator either placed permanent spawners there or the "lb v2" virus need only be dropped in place for infitinite regeneration. Regardless Pete Fats or one of his agents had to go to island sims specifically to place them.

As I said before, damned impolite. To which I'll add: aggressively so. Pete, we're all really impressed with your uber-scripting skills. Was that what you were wanting?

Just got my new sig from this thread

Andrew,
Thank you very much for your explanation on rezzing/derezzing. I appreciate the insight into the workings of the system. I posed my question out of pure curiosity. I now better understand how things are handled, and I too, like others, accept the Liden assement of the current LB v2 drone situation. I can't say that I don't worry about a rapid increase in drone networks, and what impact they may have. I know you are all very busy getting 1.6 ready for prime time, and I appreciate you taking time out to address the community's concerns. Keep up the great work.

Best Regards,
McW

This isn't a black and white issue, Andrew, and I feel you are oversimplifying by using the hyperbole "evil".

Viruses are dangerous. "How" dangerous are certainly in question. I don't think any virus is really "evil" because no object is "evil". Only humans can do good or evil actions - using a virus in a malicious or reckless way could be a "evil" act. "How evil" is also a valid question.

These things are like e-mail spam. Right now it seems malign, but when they start coming by the hundreds and carrying destructive payloads, it'll be undenaibly obvious that a wholesale ban on unsolicted replicators in SL is warranted.

I was just having a discussion with a good RL friend of mine about his first piece of spam. He was using a text browser and was in college about 12 years ago. He received his first ever piece of unsolicited email. Immediately he told his friends and they were all in shock. They felt it was a security violation, and reported it via email to the FBI. Yes, the FBI. They responded and thanked my friend for reporting it.

A decade later, we all wish the spam was stopped then.

Only in SL, it won't take a decade. It will take 6-12 months, max.

Kats

The way script execution would probably work would be something like this:

Some total chunk of the CPU cycles will be devoted to running scripts. Of that chunk some major portion of it, say 80% for argument's sake, would be made available for land owners and the other 20% would go into a common pool.

These script execution pools would only kick in if there was a contest for the resources. That is, if none of the land owners had a script and someone else were to walk into the sim with some scripted attachment then that attachment would get 100% of the script resources... if it was able to use them -- suppose it was constantly computing PI out to a thousand significant digits.

The very pseudo code might look something like:

I've got 1000 microseconds to execute some scripts and 800 of those are for landowners.
Are there any landowner scripts?

I've got (1000 - whatever_time_I've_already_used_up) microseconds left to run the common scripts.
Are there any common scripts?



If a single land owner decided to also compute PI at the same time than she would be able to compute PI about four times as fast as the outsider.

Suppose there were only three PI scripts in the sim, one owned by someone who owned 3000 m^2, one by someone who owned 1000 m^2, and one by an outsider. Mrs 3000 could compute PI about three times faster than Mr 1000, while Mr 1000 could compute PI only as fast as Mrs Outsider.

Mrs Outsider would not be using up the resources of the land on which her scripted object is located -- the resources would come out of the common pool.

This is just one way it might work -- the system is not designed yet. The main challenge we are looking into is how to efficiently schedule 1000's of scripts, each of which may not have logical places in which to relenquish the process thread that it executing it (the overhead of devoting an entire kernel thread to each script is to high). Basically, we are looking into how to schedule pico-threads from within larger threads.

--------

Yes, at the moment any player can compete for the common script execution pool of resources. Each simulator has a pool, and all of the pools add up to the global pool. If everyone were to run drones then we would have a true case of what is called "the tragedy of the commons". At the moment it is, I believe, a percieved tragedy, but since a true tragedy lies within the possibility space of SL then it is only a matter of time until it manifests itself on a global scale. Which is why we're looking into how to better allocate system resources.

Edited to add indentation to pseudo code.

the problem with this is that there are two categories of "common" sim consumers - the invited kind and the uninvited kind.

people who own land are willing to put up with the consumption of sim resources by people they asked to come (e.g. if they are holding an event).

without distinguishing between the two, it is the land owner who might get penalized by winding up with laggy events because their guests are not getting enough of the "common" resources - either because the host can't release the "private" resources to the event, or because some uninvited process is using up the "common" resources.

Sorry Hiro.

s/evil/bad

If the "lb v2" drones are self replicating then they do it in a controled manner -- not growing arbitrarily numerous. It is controlled self replication, so I think to say "It is a virus therefore it is dangerous," is incorrect.

You are percieving the tragedy. You can see it looming over the horizon. We also see it, but it has not yet arrived.

Preventing is MUCH better than curing. If you see the tragedy coming yo'd better as hell stop it now that you can then just picking up the broken pieces when it actually happens.

And no one ever said that a virus needs to be replicating indefinately to be dangerous, many viruses are in fact better programmed than many utility programs, this doesn't make them less dangerous.

Anyway ithe point it's not even: It's a virus, then it's dangerous.
It's: It's a virus, then it's against the TOS.

If we begin to make exceptions to the TOS because mr. PF is a nice guy (and sorry, but in my humble opinion nice guys don't spread viruses), or his virus is well programmed or whatever else then we go down a VERY slippery slope that will bring everyone that breaks a rule to ask for an exception. And anyway i don't even see any particular merit in this virus that could even by far warrant any possible exception.

ounce of prevention worth a pound of cure...

This is on-target with what I was going to suggest, except I think that external objects should have their execution suspended altogether if owner plots get resource-heavy.

A couple places you could look for inspiration and quick alpha-test solutions to your threading situation:

- The UNIX Kernel code, regarding process auditing and tracking (i.e. the 'ps' command).

- If any of the machines run Solaris, Sun has resources you can tap regarding threading. I suspect Linux has the same now, but Sun has been working more with the Linux community these days for inter-operation between the two.

This is just from my experience with Sun Solaris and Linux, as well as UNIX in general. I suspect YMMV, but its a great idea nonetheless.

StoneSelf -

Hmmm... it might be possible to make it such that a land owner could allow common scripts that are located on her parcel (and below some height) to use her portion of the resources. This problem is of slightly smaller magnitude than the other, but worth considering.

I should mention that I envision a future where the total script resources available will be quite large. We've seen evidence that we'll be able to make significant improvements in the speed in which LSL scripts are executed. Someday you'll be able to say, "Remember when it took a script XXX seconds to compute PI to a thousand significant digits? These days my scripts get it done in X seconds." That said, people will always be able to come up with applications that won't be able to get enough resources (a chess solver for example), however many of those should be able to fake it by using XML/RPC to speak to a remote cluster dedicated to whatever number crunching task they need. CPU cycles will be plentiful and none shall hunger... someday.

Perhaps Andrew can modify his code to allow landowners to include guests' objects' scripts in their script allocation. One way to do that would be by group, but I wouldn't necessarily want to invite event participants to become group members for our group-owned land. What land needs is another group associated with it that we can use to help manage resources, but doesn't get to act as owner. I'd love to be able to have a group for builders in our contests, so their objects don't get auto-returned, but other people's do. Likewise they could use our script allocation, etc. That would rock!

But we still need to get rid of THIS virus, now.

yours is an optimistic nature.

but if modern coding practices are any indication, i seriously doubt anything you are envisioning will happen. usage tends to fill capacity. sysadmins with large file systems will tell you this. college students using shared resources will tell you this. people with cable modems in populated areas can tell you this.

as cpu cycles become cheaper, the code becomes less optimized. that is why ms word is still a cpu hog even though the cpus are thousands of times better than in the past. or why things like xp throttles older machines that handled older os's just fine.

also, as more cpu process become available, the programmers can do more complex things. one of the reaons there aren't serious gameconsole type games in sl, is that the servers couldn't handle it. if ever sl could hand that kind of load, the those games would proliferate, and all the server cycles would be used up again.

hell, there are a couple projects (ai, cellular automata, neural networks, and robots) that i haven't bothered with in sl because they would simply run too slow. i mean if you think hoochie hair is a problem, wait until ai driven bots are wandering the grid.

Alan -

The linux kernel scheduler is very fast however the per-thread memory overhead is too high to devote an entire thread to an LSL script -- there can be thousands of scripts running in a simulator. Currently we are looking into using multi MONO threads, each of those threads executing pico-threads of LSL converted to MONO byte code (or some other virtual machine byte code interpreter)... I think -- I'm not actually participating in that effort.

Okay, Andrew... very cool to know.

But what about that this thing REZZES? What is the impact on the asset server / sims to handle the new objects being rezzed? Does this fall under the script allocation or is it common to the whole sim / SL?

I disagree. All viruses are dangerous, just as a bunny rabbit could be dangerous if put in the wrong ecosystem. What may seem like controlled reproduction in one instance can become devastating to plant and animal species in another. Second Life is a constantly evolving ecosystem. What we may think is an innocent patch could be the thing to turn "innocent" land scanner satellites into another ants out of control.

Well, I can argue semantics and say that internet viruses are controlled as well - to replicate as much as possible. But, while these are controlled timewise, they are not controlled gridwise ... they are all over the grid.


Aye, and I've acknowledged those facts in other threads. If you folks are examining the issue and the ramifications now, then SL can be rolled out with a fix / new rules / etc before this reaches critical mass. We both know fixing a bug before it becomes an issue is always more ideal to fixing it off a live server crash.

Why?

/3/2f/38889/1.html#post417792

Available land is now public. Schwan, please tell Pete his land scanners can go away, and you both can just use the upcoming RSS feed.

Andrew,

Thank to you & your team for implementing:
/3/2f/38889/1.html#post417792/3/2f/38889/1.html#post417792

This solves the immediate concern with technology rather than beaurocracy, which is something I think we all are thankful for.

I now lay down the banner on this issue. LL is investigating the long-term plan to deal with this, the short-term concern is resolved, and Pete still has the ability to get his information realtime. Seems win-win.

I've stated before that I have nothing to do with these or whatever data they collect.

The notion of these objects is intruiging to me, and the mass hysteria even more so. I hope that the overreaction of a few, doesn't end up causing LL to reform it's policy regarding such objects.

People stated their primary concerns were with the load that these bring into the system, a valid concern IMO. LL has stated that these are not malicious, lightweight, and causes no issues w/ the asset server. That still isn't good enough for some. Now we are concerned w/ the future, I see no end.

If the same people would take the time to rally and educate the masses about huge textures, open listens, and any of the other big lag producers, I bet we could increase overall sim performance in SL by 10% or more.

LL's move to make public land data available was a smart one and does indeed make this a win/win situation.

Well, you do in the sense that you've stuck up for Pete. That's why I asked you, because he refuses to explain himself on the thread and I got a less than positive response from him in IM.


There were a bunch of suggestions thrown out, from "BAN!" to "who cares?" and I agree that LL picked the most diplomatic and ... fair.

Say what? If you mean the "control" is somehow "limiting", which you seem to be implying, I don't see that. The only "control" this thing exhibits is to rapidly spread to every possible location, and then make sure every possible location remains occupied.

In what way is the "control" of this virus different from some other virus?

Is this politics? It is really starting to smell like politics.



<picks up jaw>

Wouldn't want to go around preventing tragedies, now would we.

I really want to forget about this and go back to making things. Please, Lindens, help me feel comfortable.

Are you as casual about real world threats as you are about in-world threats?

I'm with you. (Although I just can't HELP myself when absurd statements are made.)

I think the thing is a virus, but Linden says that its allowed whether its a virus or not. OK, if those are the rules, and Pete truly isn't getting an unfair free pass, then I'm OK with that.

I think its a foolish policy pronouncement (i.e., viruses are allowed as long as the author means well), but I have better things to do. They want to find out the hard way, fine.

Buster