[sldev] Re: SLDev Digest, Vol 18, Issue 66

Random Unsung ravenglassrentals at yahoo.com
Tue Jun 10 05:11:38 PDT 2008


Second Life is not a web browser. It is a world. It is a world with an economy based on intellectual property and real property rights. If you want a web browser, go outside to the Internet; if you want a world with people in it, and not merely a abstract platformist sandbox, you will have to accommodate the needs of non-scripters and non-coders who make up the business people supporting the costs of this platform and making a profit for the platform providers. 

The concept that right-clicking thereby enables stealing of proprietary images and codes everywhere else on the Internet is false, and a tendentious reading along the extremist Stallmanite lines.

Any discussion of obfuscation should be reviewed on its merits, in good faith, both to determine whether it assists in the matter of copyright theft and preserving the integrity of the original permissions system, and also with a view to functionality and scaling. 

sldev-request at lists.secondlife.com wrote: Send SLDev mailing list submissions to
 sldev at lists.secondlife.com

To subscribe or unsubscribe via the World Wide Web, visit
 /index.html
or, via email, send a message with subject or body 'help' to
 sldev-request at lists.secondlife.com

You can reach the person managing the list at
 sldev-owner at lists.secondlife.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of SLDev digest..."


Today's Topics:

   1. Re: Shadow Patch? (Argent Stonecutter)
   2. Re: Hubris, was Re: [sldev] Cache politics: performance vs
      obfuscation (Gordon Wendt)
   3. Re: Shadow Patch? (Soft)
   4. Re: Hubris, was Re: [sldev] Cache politics: performance vs
      obfuscation (Ann Otoole)
   5. Re: Hubris, was Re: [sldev] Cache politics: performance vs
      obfuscation (Gordon Wendt)
   6. Re: Cache politics: performance vs obfuscation (Michael Schlenker)


----------------------------------------------------------------------

Message: 1
Date: Mon, 9 Jun 2008 21:16:52 -0500
From: Argent Stonecutter 
Subject: Re: [sldev] Shadow Patch?
To: Second Life Developer Mailing List 
Message-ID: <82A33358-D41B-4491-A942-EB4B02DB1901 at gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On 2008-06-09, at 18:23, SignpostMarv Martin wrote:
> I believe it refers to http://www.massively.com/2008/05/29/high-end- 
> graphics-features-planned-for-second-life/

I don't think that will make it into RC10, or 1.21, or 1.22, ...




------------------------------

Message: 2
Date: Mon, 9 Jun 2008 22:16:55 -0400
From: "Gordon Wendt" 
Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs
 obfuscation
To: "Second Life Developer Mailing List" 
Message-ID:
 <493033a70806091916i6715e064kfd0efdd2045be2d2 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Irrational statements like what I keep seeing on this list are exactly why
an idiotic proposal like SVC-1919 was passed to remove UUID information from
the viewer, just because things like showing a texture UUID in the GUI can
be used for nefarious purposes wasn't and isn't a reason to cripple the
client, doubly so when it can be easily undone.  That's why there are no
copies of Mozilla Firefox (an open source web browser for those who don't
know) without right shift save image functionality or without the option to
view web page source.  You don't see people whining and moaning about their
web page source being publicly available yet people want SL to be crippled
in the same way they'd want a web browser to be crippled.

-G.W.

On Mon, Jun 9, 2008 at 9:57 PM, Lawson English  wrote:


> Eh, the middle way is best, I think.
>
> Don't support things against the TOS via the SL viewer GUI, at the very
> least. Beyond that, minor obfuscation that requires a potential thief to
> have more technical understanding of what is going on than merely accessing
> things via the standard MacOS/WIndows file GUI should be sufficient to offer
> legal protection to content creators. Any protection BEOND that, will
> require more work on the content creator. A 3rd party solution to grab
> textures as they are uploaded and run them through signature/watermarking
> before forwarding them to LL, might be an option. No doubt there are others,
> but for content creators, even slight obfuscation should offer legal
> protection. No obfuscation whatsoever, might not.
>
> In my non-legal view, of course.
>
>
> Lawson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/3e7c16db/attachment-0001.htm

------------------------------

Message: 3
Date: Mon, 9 Jun 2008 21:22:42 -0500
From: Soft 
Subject: Re: [sldev] Shadow Patch?
To: "Brandon Husbands" 
Cc: Second Life Developer Mailing List 
Message-ID:
 
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jun 9, 2008 at 4:34 PM, Brandon Husbands  wrote:
>  http://www.megafileupload.com/en/file/68953/SecondLifeShadows-zip.html
>
> Is this going to make it into rc10?

That's a long-term feature. No.

The intent of the RC branch is that subsequent RCs at a given version
number contain bug fixes only.


------------------------------

Message: 4
Date: Mon, 9 Jun 2008 20:08:01 -0700 (PDT)
From: Ann Otoole 
Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs
 obfuscation
To: Second Life Developer Mailing List 
Message-ID: <988916.32450.qm at web59107.mail.re1.yahoo.com>
Content-Type: text/plain; charset="us-ascii"

Here is what some of the people on this list come across like:

Let's say you have a town full of people worried about terrorists making home made bombs. 
Here comes a resident yelling obscenities at them, calling them stupid, yelling that there is nothing that can be done about it, and handing out flyers with instructions on how to make fertilizer bombs.
Doesn't matter if it is right or wrong the behavior is antisocial and unacceptable.

Thats the mentality I see going on. The professional nature of this list has vanished. I think LL needs to clean this list up and deal with it. 
The number of people causing problems is small and finite and I don't see much code or ideas coming from them.

This list is an LL list and as such should fall under the TOS/CS and abusive behavior should be rewarded with suspensions from Secondlife and if it continues then the SL accounts be revoked.
IMHO anyway.

If obfuscation happens to be part of a new way to manage cache so more can be stored and the performance be improved then I'm all for it. 
However, the cache performance is what counts. 
The number of bytes being transferred is becoming critical. 
And may soon become very expensive.

Can we return to finding ways to improve the cache now?


----- Original Message ----
From: Gordon Wendt 
To: Second Life Developer Mailing List 
Sent: Monday, June 9, 2008 10:16:55 PM
Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs obfuscation

Irrational statements like what I keep seeing on this list are exactly why an idiotic proposal like SVC-1919 was passed to remove UUID information from the viewer, just because things like showing a texture UUID in the GUI can be used for nefarious purposes wasn't and isn't a reason to cripple the client, doubly so when it can be easily undone.  That's why there are no copies of Mozilla Firefox (an open source web browser for those who don't know) without right shift save image functionality or without the option to view web page source.  You don't see people whining and moaning about their web page source being publicly available yet people want SL to be crippled in the same way they'd want a web browser to be crippled.

-G.W.


On Mon, Jun 9, 2008 at 9:57 PM, Lawson English  wrote:

 
Eh, the middle way is best, I think.

Don't support things against the TOS via the SL viewer GUI, at the very least. Beyond that, minor obfuscation that requires a potential thief to have more technical understanding of what is going on than merely accessing things via the standard MacOS/WIndows file GUI should be sufficient to offer legal protection to content creators. Any protection BEOND that, will require more work on the content creator. A 3rd party solution to grab textures as they are uploaded and run them through signature/watermarking before forwarding them to LL, might be an option. No doubt there are others, but for content creators, even slight obfuscation should offer legal protection. No obfuscation whatsoever, might not.

In my non-legal view, of course.


Lawson



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

------------------------------

Message: 5
Date: Mon, 9 Jun 2008 23:22:32 -0400
From: "Gordon Wendt" 
Subject: Re: Hubris, was Re: [sldev] Cache politics: performance vs
 obfuscation
To: "Second Life Developer Mailing List" 
Message-ID:
 <493033a70806092022x6fd8aca1ie241ea72a6d4e72 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Apologies to Ann for the double post since gmail at least automatically
wants to send it directly to whoever sent the original message to the list.


If you would like to skip to my ontopic comments on this conversation please
skip to the second paragraph.

@Ann Ironically you just displayed the same behavior you said should be
banned and I take great offense at you comparing people who disagree with
you on the topic of obsfucating information to terrorists.  Other than your
post here attacking other resident's directly I don't see any personal
attacks just attacks on each other's arguments which is the nature of such
discourse when not everybody agrees.   Incidentally it seems so far that LL
knows that off topic conversations and arguments go on in the list and as
long as the main conversation goes along and as long as they are quick and
not overly disruptive these arguments seem to be overlooked... this is just
from my experience so far and Rob and the other list admins take action as
they see fit without much regard to precedent.

On the topic of the issue though since this really is getting off topic I'm
sure there is some middleground in terms of performance but it seems like
high performance would require changing the fundamental way that images are
sent, recieved, and dealt with by the server and client respectively
although I'd be interested if LL or anyone else has data on where the
slowest parts of the process are since I'm not sure we know for sure that
encoding is where the bottleneck is although that is unfortunately the only
part that can really be directly seen except by LL since we don't know what
goes on serverside.

-G.W.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/e59cc824/attachment-0001.htm

------------------------------

Message: 6
Date: Tue, 10 Jun 2008 08:00:48 +0200
From: Michael Schlenker 
Subject: Re: [sldev] Cache politics: performance vs obfuscation
To: Argent Stonecutter 
Cc: Second Life Developer Mailing List 
Message-ID: <484E1890.1080604 at uni-oldenburg.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Argent Stonecutter schrieb:
> On 2008-06-09, at 02:22, Dale Mahalko wrote:
>> A move to a local MySQL database
> 
> God no.
> 
> sqlite, please. Without all the MySQL "I'm pretending to be a real 
> database engine" overhead.

SQLites pretty good for some stuff, but caching blob data is not one of 
it due to the required frequent fsync() calls needed to maintain 
transactions. (just see the current discussion around Firefox 3 being 
very slow on Ubuntu).

But MySQL is an even worse idea...

I had to write a heavily parallel (targeting some 1000 parallel writing 
threads) blob storage system for a different application and using 
SQLite, even only for storing the metadata leads to heavy lock 
contention and made the system far less scalable. Current filesystems 
like NTFS or ext3 are pretty okay for storing files and metadata, they 
are made for that kind of usecase..., its even faster to do a stat() on 
disk than to lookup stuff in sqlite in most cases.

Michael




------------------------------

_______________________________________________
SLDev mailing list
SLDev at lists.secondlife.com
/index.html


End of SLDev Digest, Vol 18, Issue 66
*************************************


       
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/ba904ff2/attachment-0001.htm


More information about the SLDev mailing list