Amen ONEFANG to SILLY threat level assignments by devs... I have always felt like my OSSL hammer was made of styrofoam because the useful functions were labelled SEVERE threats. IMO this fascination some devs have with "griefing potential" is patently absurd. There are ALWAYS illegitimate ways to use a tool/function. The proper discussion RE: advantages vs disadvantages in never even allowed.
Its sad that part of the discussion actually contains the statement ..."Threat levels are currently hard coded in the functions"... This is coding technique I teach freshman CS students to avoid. How can you expect serious developers to go along with a design plan that includes... Hard coded threat levels that may or may not match the table? Stacking threat level tables with different values and obscure "what gets called when" scenarios. You honestly want to force admins to monitor source level changes to "secured" functions to insure they are properly reflected in the table? Maybe there's someone beside me who remembers some of the other "when do we fix this shite" exchanges.. P>S> The function sleeps were always configurable by multiplier in the INI file... I ran grids with zero to minal function sleep values in 2010. I believe the Intel grid was configured the same way. On Mon, Oct 14, 2019 at 9:53 PM onefang <onef...@gmail.com> wrote: > On Tue, 15 Oct 2019 00:02:41 +0100 Leal Duarte <ajldua...@sapo.pt> > wrote: > > <snip stuff about try/catch> > > > About adding even more code on top of this, just can say that i would > > (will?) remove all this threat mess once a cleaner way (and a lot > > lighter) is found to keep the needed level of protection.. > > I'm happy that people are now seeing that some parts of the OSSL threat > level stuff are a bad idea, and are now considering ways of rolling it > back a bit, or providing work arounds for it. It's encouraging. I > have a fork of Opensim that I call opensim-SC, and one of the main > things I had done so far was my own clean up of the OSSL threat level > mess. I had seen that previously the Opensim devs would stick to > their guns about that, so didn't bother letting the devs know about my > fork. Might be time to come in from the cold. > > One of the first things people notice when using my fork is how much > faster the script engine (still Xengine) is. I managed that by > removing three things from OSSL and LL script functions. One of them > was the call to the threat level checking function for stuff that had > no threat level. Lots of things really didn't need a threat level, > like reading notecards. Another was removing the so called "LPS" > accounting. After careful inspection of the code, I found out that > "LPS" figure was not being calculated properly, and ending up in the > wrong place anyway. All it was actually achieving was slowing things > down. The major speed up I think was the last thing I did, remove > function sleeps. Back in the dim past, over a decade ago, the function > sleeps might have served a useful purpose in saving CPU resources on > Second Life servers. Now they serve no useful purpose, and obviously > just slow things down. Your average smart phone these days is probably > as fast as those ancient SL servers. > > People from three grids have been testing this, and so far only one > script had issues. In Linda Kellie's Boardwalk sim, there are swans > and trains that people can ride, with these script engine speed ups, > they zoom around at ludicrous speed. > > The other major thing I did to the script engine was review the actual > threat levels, and reduce a lot of them. > > A function to tell you if an OSSL function will be allowed is a good > idea, but it should have been there in the first place. The > http://opensimulator.org/wiki/Threat_level crash and recover trick > didn't work on some versions of Opensim. My own work around was to > listen to the DEBUG channel from a separate script in another prim (coz > scripts running in the same prim as the one triggering the error can't > hear the error message), parse the error message, and send a message to > the script that generated it, which would then keep it's own list of > functions it isn't allowed to do. This also didn't work in some > versions of Opensim. So if the proposed idea goes through, there will > be three different methods of checking threat levels, none of which > work in every version of Opensim that is currently in use. > > I'll continue my fork, since there are many other things I'm doing that > Opensim likely wont want, but you are free to have a look and grab > anything of interest. > > https://sledjhamr.org/cgit/opensim-SC/?h=master > > > possible some functions should had been added in first plane (no im > > not talking about dyn textures) > > > > Ubit. > > > > > > On 14-Oct-19 22:04, Melanie wrote: > > > The original intention of the LSL permissions system was to make a > > > script fail catastrophically. Subsequent edits have made it so that > > > using a not allowed function would not crash and stop the script, > > > which was the original, and back then intended, behavior. > > > > > > The history of this is that it should be impossible for a script to > > > detect that it is not running in SL, as an attempt to prevent the > > > creation of multi-grid griefing scripts. > > > > > > The threat of griefing never materialized as the SL griefers proved > > > to be uninterested in OpenSim. > > > > > > Still we're stuck with this legacy. However, as was said, there > > > isn't an obvious "invalid return" for some of the functions and, > > > worse, some don't return a value and expect the user to assume the > > > call has succeded. > > > > > > While I have been, at the start, an opponent of discoverability, > > > I've since changed my mind and I believe a querying function for > > > script permissions is the logical step to take. The internal code > > > is already able to determine permissions from a string version if > > > the osFunction name, exposing that would be quite trivial. > > > > > > Also some "safe" functions that used to be subject to permission > > > checks, aren't anymore. > > > > > > So this gets a +1 from me. > > > > > > The donated xmrEngine, which is now YEngine, also had, at the time > > > it was donated, a try/catch mechanism. I am not aware of how much > > > of that remains after the removal of the extension APIs and the > > > linux-only parts that caused it to become YEngine. However, until > > > it, or it's successor(s) become the standard engine and any engines > > > not able to use try/catch are removed, the API can't really make > > > use of it. > > > > > > - Melanie > > > > > > > > > > > > > > > ---- On Mon, 14 Oct 2019 19:42:56 +0000 Haravikk > > > <mailto:open...@haravikk.me> wrote ---- > > > > > > > > > > > > > > >> On 14 Oct 2019, at 15:12, dz <mailto:d...@bitzend.net> wrote: > > >> > > >> just an observation from a casual observer with decades of > > >> software design experience... > > >> > > >> Wouldn't it be more productive to wrap all OSSL function calls > > >> in error handling so the response is "correct" regardless of the > > >> permissions? Adding another seperate function that will ALWAYS > > >> need to be called before any OSSL function just adds bloat, > > >> confusion, and removes any incentive for the problem to be > > >> handled "correctly" (looks at the forum name) OOO ya > > >> nvm… > > > The problem with that is that a default return value may not be > > > distinguishable as an error; for example, for a function that > > > returns a list, an empty list might make sense, but you wouldn't be > > > able to tell if the return was genuinely empty, or the call wasn't > > > allowed. > > > > > > In an ideal world we'd use C# or another language with exception > > > handling, as that's a much cleaner way to handle capturing of > > > recoverable errors. Of course it's also a lot of work. > > > > > > I wonder though, how difficult would it be to expose a minimal > > > version of exception handling to LSL? i.e- a very basic try/catch > > > block (no multiple catch blocks, or catches of specific types, just > > > catch everything)? > > >> On Sun, Oct 13, 2019 at 10:27 AM Mike Higgins > > >> <mailto:m...@kayaker.net> wrote: > > >>> Yeah, there is an example of that crash and recover trick at > > >>> http://opensimulator.org/wiki/Threat_level, at the bottom of the > > >>> page. > > >>> > > >>> I have done that and it works after SPAMMING EVERY AVATAR IN THE > > >>> REGION once. Which is still annoying. > > >>> > > >>> On 10/13/2019 4:25 AM, Michel Beauregard wrote: > > >>>> Its a good idea to have a function that test if a osl function > > >>>> is > > >>> available to a owner in a specific location. > > >>>> For now there is a way to test for osl function scriptwise. A > > >>>> failing > > >>> osl function cause a crash of the event calling it. So what I do > > >>> is on state_entry I call a timer with a fake call to all the OSL > > >>> function(s) to be use in my scripts . If the timer failes it > > >>> means that one or any of the function I need is not allowed . And > > >>> the script simply spell out to the owner of that object that it > > >>> cant be use and abort. So at least it does not repeatedly spam > > >>> the region . > > >>>> I will post an example of the script I use in my user page in > > >>>> opensim if > > >>> you like more detail. > > >>> (http://opensimulator.org/wiki/User:Gimisa) . With your function > > >>> you might be able to detect the failure of the osl function call > > >>> instead of sending it to report inworld and act by sending back a > > >>> message to the script for action. Allowing me to use the reply in > > >>> any way I need instead of using timer failure. > > >>>> hope it helps > > >>>> GiMiSa > > > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > _______________________________________________ Opensim-dev mailing list Opensim-dev@opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
