> On 12 Aug 2018, at 16:58, Ethan A. Gardener <eeke...@fastmail.fm > <mailto:eeke...@fastmail.fm>> wrote: > On Sun, Aug 12, 2018, at 11:03 AM, Haravikk wrote: >> >>> On 12 Aug 2018, at 09:52, Luisillo Contepomi <luisillocontep...@gmail.com >>> <mailto:luisillocontep...@gmail.com>> wrote: >>> >>> When you build a cube in a region and after you delete de cube will >>> remain in database forever or until you erase it manually >>> >>> Best regards, >>> Luisillo >> >> I don't believe this is quite true; when you create an object in a >> region it exists only within the region where it is located, if you >> "delete" it then it is transferred to your inventory, if you then delete >> it from your inventory as well then it should be gone for good. > > You believe, or you know? In technical fields, the difference can mean > everything.
I know. I said "I believe" because I was trying to give the benefit of the doubt, as what Luisillo said can be true, especially of other asset types, but isn't always true of objects in particular. It is for possible for a cube to never become an asset, for example if the region it is in crashes without saving, or is deleted without returning anything to user inventory, all such objects simply cease to exist. Any textures applied to those objects however would remain in the asset server. >> Using vanilla >> LSL for example it is possible to apply textures, trigger sounds and >> fetch notecards using a GUID. > > Um... this is where I think the OpenSim project should have taken the > position, "UUIDs alone are unreliable." While I kind of agree, it would mean a pretty big departure from vanilla LSL which OpenSim was being made compatible with at the time. I mean you could reasonably argue OpenSim should never have tried to support LSL in the first place since it's a terrible language that never should have been in Second Life either, but what's done is done! That said, I wouldn't say UUIDs are unreliable, just that you need to know when it's appropriate to use them; they're fine for non-transferable objects so long as the asset exists in an object/user inventory somewhere, i.e- you shouldn't use the UUID unless you know where the asset it references actually exists, and you shouldn't at all for anything transferable that could end up on another grid. Cases where referenced assets have vanished on SL were I think times when LL were trying to solve the exact same problem, and hadn't considered scripts references at all, but LL and a lack of thought given to scripting has been the status quo from day one 😏 >> The only way to safely flush out textures, sounds and notecards (and >> animations if you allow GUID fetching of these) would be to scour every >> object, script and notecard on your grid for possible GUIDs, but even >> then this is only safe if you don't allow scripts to contact external >> services (as a user could store GUIDs in an external database for >> example). > > The relatively popular Boehm garbage collector for C and C++ can operate in > exactly this way, but I'll admit that a grid database is an awful lot bigger > and slower than the memory of one computer program. Yeah, you'd have to inspect every single script and every script VM in every single inventory, object inventory, and in world object inventory in every region on a grid, and even then some regions could be offline (e.g- OS Grid where you can join or leave at any time). If you're certain that you don't need to preserve such items, or the problem is bad enough that you don't care to, then it's reasonable to skip such a step; I was just trying to highlight why an asset can exist in the asset server without existing in an region or inventory, and still be unsafe to delete. >> This is I think why in SecondLife it costs L$10 per upload, as it stops >> users going overboard with uploads, this is also the reason why images >> are stored at limited sizes, sounds and animations are limited in length >> etc. > > Hmm. The upload fee was explained as, "An economy needs sources and sinks. > The upload fee is one of the sinks." They may have had multiple reasons, I > suppose. All the other limitations might be explained as trying to limit > their bandwidth. Textures have the additional problem of taking up memory in > the graphics card, a big problem in the early '00s as graphics cards had > relatively little memory couldn't decompress images on the fly. It may still > be a problem: a 2GB graphics card can be a big help, but that might be some > other factor. Sure, it's not the sole reason, but even a price as low as L$10 is a deterrent to uploading things excessively. It's essentially the same principle as charging 5p for plastic bags to cut down on plastic bag pollution, it's not much but it's surprisingly effective. >> At the end of the day though the question is; how limited is your >> storage really? The only cost of unused assets is in a bit of wasted >> hard storage, but storage is pretty cheap, so unless your grid is >> growing beyond your ability to match it then you might be trying to >> solve a problem where the solution could be more destructive than the >> problem itself 😏 > > I'm told that by the end of InWorldz, its asset server was growing by a > terrabyte every month! There's nothing "more destructive" about trying to > limit that kind of growth! Is this such a case though? Even so, asset cleaning isn't really going to limit that kind of growth much; unless a grid is accumulating a similar amount of unused assets each month then at the end of the day you're still talking about a huge volume of new assets being the real problem there. At that kind of level though, 1tb a month is 12tb a year, a 12tb hard drive is around $400 now. With the right kind of setup it wouldn't cost a lot more than that to add storage, or swap older drivers for newer, larger ones to keep ahead of it. Not ideal, and you'd better hope someone's helping to cover those, and other costs, but it doesn't have to be the end of the (virtual) world. 😀 _______________________________________________ Opensim-users mailing list Opensim-users@opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
