No. All that clutter stays around forever until deleted or until some catastrophic crash of the asset db :)
On Sun, Aug 12, 2018 at 1:02 PM Luisillo Contepomi < [email protected]> wrote: > >I said "I believe" > > I've tried it and it seems to work as you explain. > ;) > > 2018-08-12 21:31 GMT+02:00 Haravikk <[email protected]>: > > > >> On 12 Aug 2018, at 16:58, Ethan A. Gardener <[email protected] > <mailto:[email protected]>> wrote: > >> On Sun, Aug 12, 2018, at 11:03 AM, Haravikk wrote: > >>> > >>>> On 12 Aug 2018, at 09:52, Luisillo Contepomi < > [email protected] <mailto:[email protected]>> 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 > > [email protected] > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users > _______________________________________________ > Opensim-users mailing list > [email protected] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users > _______________________________________________ Opensim-users mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
