Hubris, was Re: [sldev] Cache politics: performance vs obfuscation

[Ann Otoole]

I'm aware of the challenge/opportunity. Thus why I don't have much to say about it in negative unproductive terms (anymore :P ).
My interest is in finding a way to increase both the storage capacity and efficiency of storing/loading while increasing protection against unauthorized access.
My gut feeling is what I want will require better personal computer hardware.

I do not think it is simple. This will require some creative thinking and hard work.

If everyone had a powerful 64 bit pc/os with 4gb ram and high end video card then maybe an in memory database might be an interesting concept.
But everyone doesn't have enough memory and processing power yet.

Oracle is moving in this direction for heavy transaction systems to get hundreds of thousands of transactions per second with resiliency between network disconnects. 
Is the mysql effort doing anything similar?

I doubt a lot of low hanging fruit is available The number and size factor of an entire sim's textures is large. The more you store the longer to find it to reload. etc etc.

Doesn't mean we can't plan ahead. And try.


----- Original Message ----
From: Dante Tucker <danteferret at gmail.com>
To: ordinal.malaprop at fastmail.fm
Cc: Second Life Developer Mailing List <sldev at lists.secondlife.com>
Sent: Monday, June 9, 2008 5:38:57 PM
Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation

Now don't forget everything here is just opinion. The ultimate decision of what happens with the client is up to Linden Labs. My point is they will listen to everyone before making a decision, not just the few that rant here in this list. We look at things from a technical perspective, others will argue a different perspective. And in the end LL will take all into account. It's a balance really, no reason to get mad.


On Mon, Jun 9, 2008 at 5:22 PM,  <ordinal.malaprop at fastmail.fm> wrote:


On 9 Jun 2008, at 11:34, Thomas Grimshaw wrote:


Dante Tucker wrote:

Lets all just stop pretending anyone who wants to steal textures can't with the current system. Anyone who wants them can already get them. The only thing storing data raw would do is make them more accesable to people who don't want them and have no knoledge of how to get them currently. And if they don't want them then whats the harm?

Agreed.

I tire of people moaning about IP security.

Your stuff is already stolen, deal with it.

~Tom

Not to pick on Tom particularly here, but this is the sort of m message that reinforces my opinion that:

(a) the people involved in discussing assets don't understand what those _creating_ the assets want or think;
(b) they don't care.

The level of snobbery applied here is breathtaking, endless references to pitchforks ho ho, you know, they're all irrational peasants. But even in the current situation, textures not being instantly obtainable by just going to the right directory and dragging to somewhere else is a disincentive to pirates.

YES, we do all know about glintercept and all the other ways to get hold of textures. YES, we know that there is an intrinsic problem here, that displaying the damn assets implies that they are received by the client. YES, we've all heard these teenage extropian "information wants to be free" tropes, thanks all the same.

Amazingly enough, people appreciate the practical issues. What they don't like is the idea that they are being treated as idiots and rubes by LL and assorted geeky types because they dare to get worried about the reason that they are there and building the world for you lot to play about with in the first place. Because, you know, if it wasn't for people who make content, you and I would not be here discussing this stuff, as I've said before.

If you can't offer anything to content creators apart from "ha ha your stuff has already been stolen stupid n00bs" then you might as well close the whole company down right now.
_______________________________________________
Click here to unsubscribe or manage your list subscription:
/index.html


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/648defe7/attachment.htm