Second Life Wiki - User contributions [en]

Viewer Authentication Critique

2007-10-01T12:32:57Z

Whoops Babii: /* Signatories */

This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.

For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]

== Summary ==

The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem.

There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).

Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.

There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.

Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.

It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.

== Security ==

=== LL's Objectives ===
* To mitigate the danger of password capturing Trojans masquerading as third party viewers
* Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.

=== Pros ===
* Viewer does not have to process (and "see") username and password

=== Cons ===
* The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.
** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).
** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.
* But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.
 
* Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!
** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.
*** This kind of attack is not theoretical, phishing websites are a criminal industry.
*** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer
** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns
** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)
* So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.
 
* And the mechanism itself is relatively inflexible.
** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program
** Links to secondlife:// can not pass parameters to the program
*** In fact allowing that was a security flaw recently found and fixed in the SL client. :(
** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.
 
* Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)
** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.

=== Alternatives ===
* One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)
* lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)
* separate passwords for website account and being inworld
* Account restrictions
* Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)
* Do nothing, keep everything as it is.
** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers
** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises
 
* This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.
** CRAM-MD5 or a similar challenge-response type
** Dictionary check to reject insecure passwords

== Flexibility ==

=== LL's Objectives ===
* Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems
* Extension of this to allow non-LL applications and web sites to participate in this single sign on system.

=== Pros ===
* Enables username/password authentication to work on third party sites without them having to "see" username and password

=== Cons ===
* This is really an unrelated issue...
** The client doesn't need to depend on the website for this purpose, or this could be a command line option.
** The client could just as easily be the 'authentication source' as the website.
*** Via a "go to website" link in the client that passed an equivalent token.
 
* As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes

=== Alternatives ===
* Use this mechanism for websites (including third party) only but not for viewers
 
* Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]
** OpenID - [http://openid.net/]
** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]
** Shibboleth - [http://shibboleth.internet2.edu/]
** CAS - [http://www.ja-sig.org/products/cas/]
*** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security

== Persistence ==

=== LL's Objectives ===
* To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.

=== Pros ===
* Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different

=== Cons ===
* As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.
* Inconvenient for those with alts or multiple clients
** Cumbersome to change alts and logon with multiple alts
** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL
** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes
* Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.
* Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld
* starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.
* this would have an impact on the architecture discussions for a future open grid.

=== Alternatives ===
* As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).
* Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".

== Signatories ==

Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with.

* [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)
* [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)
* [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)
* [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)
* [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)
* [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)
* [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)
* [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)
* [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)
* [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT)
* [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)
* [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)
* [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)
* [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)
* [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)
* [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)
* [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)

Viewer Authentication Critique

2007-10-01T12:29:38Z

Whoops Babii: /* Signatories */

This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.

For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]

== Summary ==

The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem.

There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).

Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.

There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.

Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.

It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.

== Security ==

=== LL's Objectives ===
* To mitigate the danger of password capturing Trojans masquerading as third party viewers
* Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.

=== Pros ===
* Viewer does not have to process (and "see") username and password

=== Cons ===
* The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.
** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).
** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.
* But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.
 
* Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!
** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.
*** This kind of attack is not theoretical, phishing websites are a criminal industry.
*** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer
** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns
** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)
* So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.
 
* And the mechanism itself is relatively inflexible.
** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program
** Links to secondlife:// can not pass parameters to the program
*** In fact allowing that was a security flaw recently found and fixed in the SL client. :(
** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.
 
* Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)
** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.

=== Alternatives ===
* One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)
* lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)
* separate passwords for website account and being inworld
* Account restrictions
* Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)
* Do nothing, keep everything as it is.
** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers
** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises
 
* This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.
** CRAM-MD5 or a similar challenge-response type
** Dictionary check to reject insecure passwords

== Flexibility ==

=== LL's Objectives ===
* Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems
* Extension of this to allow non-LL applications and web sites to participate in this single sign on system.

=== Pros ===
* Enables username/password authentication to work on third party sites without them having to "see" username and password

=== Cons ===
* This is really an unrelated issue...
** The client doesn't need to depend on the website for this purpose, or this could be a command line option.
** The client could just as easily be the 'authentication source' as the website.
*** Via a "go to website" link in the client that passed an equivalent token.
 
* As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes

=== Alternatives ===
* Use this mechanism for websites (including third party) only but not for viewers
 
* Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]
** OpenID - [http://openid.net/]
** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]
** Shibboleth - [http://shibboleth.internet2.edu/]
** CAS - [http://www.ja-sig.org/products/cas/]
*** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security

== Persistence ==

=== LL's Objectives ===
* To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.

=== Pros ===
* Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different

=== Cons ===
* As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.
* Inconvenient for those with alts or multiple clients
** Cumbersome to change alts and logon with multiple alts
** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL
** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes
* Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.
* Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld
* starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.
* this would have an impact on the architecture discussions for a future open grid.

=== Alternatives ===
* As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).
* Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".

== Signatories ==

Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with.

* [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)
* [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)
* [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)
* [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)
* [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)
* [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)
* [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)
* [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)
* [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)
* [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT)
* [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)
* [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)
* [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)
* [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)
* [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)
* [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)
* [[User:Dana Fagerstrom|Dana Fagerstrom]] [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)

SLDev Resident Names

2007-09-10T13:32:22Z

Whoops Babii: Added myself to the list

[[SLDev]] > '''SLDev Resident Names'''

Most things associated with Second Life development (in-world meetings, wiki editing, JIRA) are done using Second Life names, but posting on the mailing list is often done using another name (real name or non-Second Life alias). This page is intended as a decoder ring for people to figure out who's who on the [[SLDev]] mailing list.

Don't reveal any information you don't want to, but if you post messages to the SLDev mailing list under a different name than your Second Life Resident name, please consider dropping your name in the table. (Tip: putting three tildes, e.g. "<nowiki>~~~</nowiki>", will automatically convert to your name and a link to your username on this wiki) :

{|border="1" cellpadding="2" class=sortable
|-
!| SLDev Posting Name
!| Second Life Resident Name
|-
| Andre Roche || [[User:Ryozu Kojima|Ryozu Kojima]]
|-
| Andy Estes || [[User:Drewan Keats|Drewan Keats]]
|-
| Callum Lerwick || [[User:Seg Baphomet|Seg Baphomet]]
|-
| Dirk Moerenhout || [[User:Blakar Ogre|Blakar Ogre]]
|-
| Dzonatas || [[User:Dzonatas Sol|Dzonatas Sol]]
|-
| Ettore Pasquini || [[User:Abstra Apparatchik|Abstra Apparatchik]]
|-
| Harold "LabRat" Brown || [[User:Thraxis Epsilon|Thraxis Epsilon]]
|-
| Jason Giglio || [[User:Gigs Taggart|Gigs Taggart]]
|-
| Laurent Laborde || [[User:Kerunix Flan|Kerunix Flan]]
|-
| Lawson English || [[User:Saijanai Kuhn|Saijanai Kuhn]]
|-
| Matt Kimmel || [[User:Feep Larsson|Feep Larsson]]
|-
| Mike Monkowski || [[User:Mm Alder|Mm Alder]]
|-
| Nik Radford || [[User:Nik Woodget|Nik Woodget]]
|-
| Paul Nolan || [[User:Paul Churchill|Paul Churchill]]
|-
| Rob Lanphier || [[User:Rob Linden|Rob Linden]]
|-
| Ben Byer || [[User:Bushing Spatula|Bushing Spatula]]
|-
| Dana Fagerstrom || [[User:Whoops Babii|Whoops Babii]]
|}

User:Soft Linden/scratch

2007-06-29T13:25:37Z

Whoops Babii: /* sldev Meeting Times */

== sldev Meeting Times ==

Add your SL name and mark the time slots (in Pacific/SLT) that are generally agreeable and available for developer meetings. Don't worry about breaking it down to specific days - I'm just looking for clusters here.

Name Weekday 6a 9a 12 15 18 21 Weekend 6a 9a 12 15 18 21
Soft Linden * * * * * * * * * * * *
Nick * * * * * * * *
John Hurliman * * * * * *
Able Whitman * * * * * * *
Jason Giglio * * * * * * * *
Boroondas Gupte * * * * * *
Dana Fagerstrom * * *

== Old Patches Possibly Wanting Love ==
sldev PATCH build fixes for gcc 4 
Olivier Blin blino at mandriva.com 
Mon Jan 8 17:56:35 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-January/000026.html

sldev PATCH: Copy UUID pie menu item 
John Hurliman jhurliman at wsu.edu 
Sat Jan 13 01:56:11 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-January/000094.html

sldev alternative os support? 
Todd T. Fries sl at email.fries.net 
Mon Jan 22 17:20:24 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-January/000176.html

sldev OpenJPEG MAX_PATH issue 
David Fries david at fries.net 
Sat Jan 20 14:43:49 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-January/000180.html

sldev Re: LLOctree crash (weird crash) 
Dylan Alex Simon dylan at dylex.net 
Wed Jan 24 18:36:22 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-January/000232.html

sldev New First Look source code 
Ismail Dönmez ismail at pardus.org.tr 
Sat Feb 3 04:09:22 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-February/000315.html

sldev OpenJPEG meta decode, Second Life patches 
David Fries david at fries.net 
Sun Feb 11 14:26:06 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-February/000362.html

sldev jinclude.h ? 
David Fries david at fries.net 
Wed Feb 14 20:00:27 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-February/000425.html

sldev Let xmlrpc-epi use already installedversion of expat. 
Guido guidoj at users.sourceforge.net 
Mon Feb 19 07:46:59 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-February/000459.html

sldev Ubuntu Runtime Error SDL 
David Fries david at fries.net 
Tue Feb 27 21:00:24 PST 2007 
https://lists.secondlife.com/pipermail/sldev/2007-February/000672.html

SLDev-Traffic 16

2007-06-20T22:48:22Z

Whoops Babii: /* Data Alignment */

{{SLDevTraffic}}

sldev-traffic no 16

sldev discussions through June 15, 2007

== "About Land" Floater Patch ==
Zi Ree offered a patch, attached to {{JIRA|VWR-1140}}, which makes the About Land floater resizable, citing problems with some widgets, such as the ban list, being far too small. There wasn't follow-up on-list, but Zi's patch was accepted and applied. Thanks, Zi!

== Visual Studio 2005 (VS8) Project Files ==
Nicholas Beresford posted a set of up-to-date Visual Studio 2005 project files, explaining some small amount of trouble in getting them to work. Listmember Dirk Moerenhout notes the importance of the 2005 project files, in that the "Express" edition of the 2005 compiler is free, opening up access to developers who can't or won't spring for the Microsoft tools.

This lead to some discussion within Linden Lab about the best way to maintain 2005 projects as an ongoing concern, and one of our release engineers has created a script that scans for disparity in the files present in VS7 and VS8 projects, noting "Extending this to cover XCode and SCons files should be doable as well." In the interim, until the 2005 process is smoothed out, Brian O'Sullivan (Linden) confirmed on-list that Linden Lab would gladly accept VS2005 project patches. Nicholas posted a set at {{JIRA|VWR-1151}}, which Brian has assigned to himself. The first set had conflicts with other work, but Nicholas has posted a newer set.

Of note, for the curious, we still use 2003 as the primary platform internally, but are pushing to erase the last restrictions preventing our using 2005.

== Data Alignment ==
Dana Fagerstrom previously noted success in creating a Solaris build of the viewer on x86 and he's now doing the same for SPARC. One issue Dana runs across while working on the SPARC port are buffers that get created as U8's and are then cast as U32's, etc. Dana requests that developers consider adding explicit alignment. For now, Dana's making a patch set with the alignment #ifdef'ed for SPARC so that Lindens can consider whether the change should be made uniformly.

A global buffer with explicit alignment looks like this: 
U8 mData[UUID_BYTES] __attribute__ ((aligned(8)));

The above aligns the data across 8 byte boundaries.

A dynamic allocation of a U8 buffer of <CODE>size</CODE> bytes with word boundary alignment
looks like this: 
U8* mBuffer = (U8 *)(new U32[size/4 + 1]);

Each of the above ensures that the data is aligned properly and is portable across CPU architectures.

Dana is currently working with compiler experts to see if there are options that one could include to avoid such problems.

== Please Use .txt File Extensions in JIRA ==
Dzonatas Sol suggests that text-based attachments carry a .txt file extension in JIRA. The rationale is that JIRA doesn't add a MIME type, preventing users from viewing the attachment within the browser without the file extension as a type hint.

== Email to Objects Broken ==
Kamilion pointed out that scripts were not receiving email from outside the secondlife.com domain, posting a sample script. This lead to a lengthy discussion about past unreliability in the XMLRPC and mail systems, with some speculation about how reliability could be improved. Kelly Washington (Linden) posted some details about the various communication methods available, noting that llHTTPRequest is the simplest and most reliable of the communication methods. Kelly also noted that Linden Lab were investigating the issue, and Kamilion confirmed that he'd heard back from James Linden, and that Don Linden was leading a recovery effort. Chance Unknown confirmed that some very old messages - as old as 2 weeks - were now coming through.

Any further observations about delays or breakage would be appreciated!

== Another Call for CPU Statistics ==
In the context of a thread about CPU optimization and what programmatic and manual optimizations might help and hurt different platforms, Dirk Moerenhout made a renewed call for statistics about what kinds of CPUs are in use by Second Life residents. To date, there hasn't been a posting of this information, however Laurent Laborde posted a link to a [http://www.steampowered.com/status/survey.html hardware survey] from Valve, makers of Half Life.

== Dead Flag ==
Max Okumoto noted that the LL_USE_KDU flag wasn't actually used in the viewer, and Phoenix Linden confirmed that it had now been removed internally. Thanks for pointing that out, Max.

== LLMuteList::loadFormFile() Parses the Mute List Improperly ==
Able Whitman found a discrepancy between how the mute list was formatted and how it was parsed. Brian O'Sullivan (Linden) confirmed the discrepancy and fixed the parsing internally. Nicholaz Beresford gave kudos for a nice catch - agreed!

== Sculpted Prims - .OBJ Import ==
Dzonatas Sol posted a basic .OBJ importer. .OBJ files are a common 3D mesh format, and Dzonatas' importer can handle 64x63 sphere meshes "made with Wings3D, or other modelerst hat can create such meshes." Qarl Linden expressed concern about the importer, as it would only work with very specifically formatted meshes. Periapse Linden suggested that Linden Lab should provide more details on what would make the patch usable at Dzonatas' offer to further tailor the code.

== Particle Appearance Changed ==
Argent Stonecutter noted that the appearance of particles had changed in the 1.17 viewer. Nicholaz Beresford didn't see any relevant changes in a comparison of the old and new partsim and partsource.

Argent reported progress in working with Farallon: 
The problem is that if you have "PSYS_PART_FOLLOW_SRC_MASK" then
"PSYS_SRC_BURST_RADIUS" is ignored... you can't create a particle
system that uses "PSYS_PART_FOLLOW_SRC_MASK" and starts the particle
emission at a distance. Why not, I don't know, it's always been an
annoyance to me, but I'd just gotten used to it. Farallon had some
particle systems he'd modified that had a non-zero radius set, and he
hadn't zeroed them out...

Before 1.15 or so, it acted as if "PSYS_SRC_BURST_RADIUS" was zero.

Now it seems to create the particles at "PSYS_SRC_BURST_RADIUS" then
applies the "PSYS_PART_FOLLOW_SRC_MASK" rule on the following frame.

The correct "fix" is uncertain.

Nicholaz pointed to a related JIRA at {{JIRA|VWR-1154}}, which is as-of-yet unresolved. Discussion continues about whether to support the old misuse of the system, or to break content by making the particle system work as designed and described in the documentation.

== Lex and Yacc Gurury ==
Soft Linden investigated {{JIRA|VWR-68}}, which was designed to fold some constant expressions in LSL and fix a problem where a subtraction expression could be swallowed as a negative number, creating a nonsense pair of tokens. Soft noted a case where constants could be folded improperly and asked for suggestions on a fix. Dzonatas Sol offered some input, and Argent Stonecutter, author of the original patch, offered a follow-up. Soft has promised to test and import the result.

== Bug Triage ==
This is a reminder that Rob Lanphier (Linden) holds bug triage sessions on Mondays. This is a perfect opportunity to weigh in on JIRA issues that need attention, or that may proscribe fixes you disagree with.

The agenda can always be found [https://wiki.secondlife.com/wiki/Bug_triage/Agenda on the wiki], and volunteers, including Dzonatas Sol and Gigs taggart have been doing a fantastic job of keeping the agenda up to date!

== 1.17 PJIRA Cleanup ==
Dzonatas Sol also volunteered to do some maintenance on the public JIRA following the 1.17 release. I love y'all so much. :)

SLDev-Traffic 16

2007-06-19T19:31:52Z

Whoops Babii: /* Data Alignment */

{{SLDevTraffic}}

sldev-traffic no 16

sldev discussions through June 15, 2007

== "About Land" Floater Patch ==
Zi Ree offered a patch, attached to {{JIRA|VWR-1140}}, which makes the About Land floater resizable, citing problems with some widgets, such as the ban list, being far too small. There wasn't follow-up on-list, but Zi's patch was accepted and applied. Thanks, Zi!

== Visual Studio 2005 (VS8) Project Files ==
Nicholas Beresford posted a set of up-to-date Visual Studio 2005 project files, explaining some small amount of trouble in getting them to work. Listmember Dirk Moerenhout notes the importance of the 2005 project files, in that the "Express" edition of the 2005 compiler is free, opening up access to developers who can't or won't spring for the Microsoft tools.

This lead to some discussion within Linden Lab about the best way to maintain 2005 projects as an ongoing concern, and one of our release engineers has created a script that scans for disparity in the files present in VS7 and VS8 projects, noting "Extending this to cover XCode and SCons files should be doable as well." In the interim, until the 2005 process is smoothed out, Brian O'Sullivan (Linden) confirmed on-list that Linden Lab would gladly accept VS2005 project patches. Nicholas posted a set at {{JIRA|VWR-1151}}, which Brian has assigned to himself. The first set had conflicts with other work, but Nicholas has posted a newer set.

Of note, for the curious, we still use 2003 as the primary platform internally, but are pushing to erase the last restrictions preventing our using 2005.

== Data Alignment ==
Dana Fagerstrom previously noted success in creating a Solaris build of the viewer on x86 and he's now doing the same for SPARC. One issue Dana runs across while working on the SPARC port are buffers that get created as U8's and are then cast as U32's, etc. Dana requests that developers consider adding explicit alignment. For now, Dana's making a patch set with the alignment #ifdef'ed for SPARC so that Lindens can consider whether the change should be made uniformly.

A global buffer with explicit alignment looks like this: 
U8 mData[UUID_BYTES] __attribute__ ((aligned(8)));

Of course the above could cause concern because the #define UUID_BYTES, which is 8, can not be used in the <CODE>aligned</CODE> attribute. However, there are only a few of these globals that need such alignment so at the moment they are workable.

A dynamic allocation of a U8 buffer of <CODE>size</CODE> bytes with word boundary alignment
looks like this: 
U8* mBuffer = (U8 *)(new U32[size/4 + 1]);

Each of the above ensures that the data is aligned properly and is portable across CPU architectures.

== Please Use .txt File Extensions in JIRA ==
Dzonatas Sol suggests that text-based attachments carry a .txt file extension in JIRA. The rationale is that JIRA doesn't add a MIME type, preventing users from viewing the attachment within the browser without the file extension as a type hint.

== Email to Objects Broken ==
Kamilion pointed out that scripts were not receiving email from outside the secondlife.com domain, posting a sample script. This lead to a lengthy discussion about past unreliability in the XMLRPC and mail systems, with some speculation about how reliability could be improved. Kelly Washington (Linden) posted some details about the various communication methods available, noting that llHTTPRequest is the simplest and most reliable of the communication methods. Kelly also noted that Linden Lab were investigating the issue, and Kamilion confirmed that he'd heard back from James Linden, and that Don Linden was leading a recovery effort. Chance Unknown confirmed that some very old messages - as old as 2 weeks - were now coming through.

Any further observations about delays or breakage would be appreciated!

== Another Call for CPU Statistics ==
In the context of a thread about CPU optimization and what programmatic and manual optimizations might help and hurt different platforms, Dirk Moerenhout made a renewed call for statistics about what kinds of CPUs are in use by Second Life residents. To date, there hasn't been a posting of this information, however Laurent Laborde posted a link to a [http://www.steampowered.com/status/survey.html hardware survey] from Valve, makers of Half Life.

== Dead Flag ==
Max Okumoto noted that the LL_USE_KDU flag wasn't actually used in the viewer, and Phoenix Linden confirmed that it had now been removed internally. Thanks for pointing that out, Max.

== LLMuteList::loadFormFile() Parses the Mute List Improperly ==
Able Whitman found a discrepancy between how the mute list was formatted and how it was parsed. Brian O'Sullivan (Linden) confirmed the discrepancy and fixed the parsing internally. Nicholaz Beresford gave kudos for a nice catch - agreed!

== Sculpted Prims - .OBJ Import ==
Dzonatas Sol posted a basic .OBJ importer. .OBJ files are a common 3D mesh format, and Dzonatas' importer can handle 64x63 sphere meshes "made with Wings3D, or other modelerst hat can create such meshes." Qarl Linden expressed concern about the importer, as it would only work with very specifically formatted meshes. Periapse Linden suggested that Linden Lab should provide more details on what would make the patch usable at Dzonatas' offer to further tailor the code.

== Particle Appearance Changed ==
Argent Stonecutter noted that the appearance of particles had changed in the 1.17 viewer. Nicholaz Beresford didn't see any relevant changes in a comparison of the old and new partsim and partsource.

Argent reported progress in working with Farallon: 
The problem is that if you have "PSYS_PART_FOLLOW_SRC_MASK" then
"PSYS_SRC_BURST_RADIUS" is ignored... you can't create a particle
system that uses "PSYS_PART_FOLLOW_SRC_MASK" and starts the particle
emission at a distance. Why not, I don't know, it's always been an
annoyance to me, but I'd just gotten used to it. Farallon had some
particle systems he'd modified that had a non-zero radius set, and he
hadn't zeroed them out...

Before 1.15 or so, it acted as if "PSYS_SRC_BURST_RADIUS" was zero.

Now it seems to create the particles at "PSYS_SRC_BURST_RADIUS" then
applies the "PSYS_PART_FOLLOW_SRC_MASK" rule on the following frame.

The correct "fix" is uncertain.

Nicholaz pointed to a related JIRA at {{JIRA|VWR-1154}}, which is as-of-yet unresolved. Discussion continues about whether to support the old misuse of the system, or to break content by making the particle system work as designed and described in the documentation.

== Lex and Yacc Gurury ==
Soft Linden investigated {{JIRA|VWR-68}}, which was designed to fold some constant expressions in LSL and fix a problem where a subtraction expression could be swallowed as a negative number, creating a nonsense pair of tokens. Soft noted a case where constants could be folded improperly and asked for suggestions on a fix. Dzonatas Sol offered some input, and Argent Stonecutter, author of the original patch, offered a follow-up. Soft has promised to test and import the result.

== Bug Triage ==
This is a reminder that Rob Lanphier (Linden) holds bug triage sessions on Mondays. This is a perfect opportunity to weigh in on JIRA issues that need attention, or that may proscribe fixes you disagree with.

The agenda can always be found [https://wiki.secondlife.com/wiki/Bug_triage/Agenda on the wiki], and volunteers, including Dzonatas Sol and Gigs taggart have been doing a fantastic job of keeping the agenda up to date!

== 1.17 PJIRA Cleanup ==
Dzonatas Sol also volunteered to do some maintenance on the public JIRA following the 1.17 release. I love y'all so much. :)

SLDev-Traffic 16

2007-06-19T12:27:09Z

Whoops Babii: /* Data Alignment */

{{SLDevTraffic}}

sldev-traffic no 16

sldev discussions through June 15, 2007

== "About Land" Floater Patch ==
Zi Ree offered a patch, attached to {{JIRA|VWR-1140}}, which makes the About Land floater resizable, citing problems with some widgets, such as the ban list, being far too small. There wasn't follow-up on-list, but Zi's patch was accepted and applied. Thanks, Zi!

== Visual Studio 2005 (VS8) Project Files ==
Nicholas Beresford posted a set of up-to-date Visual Studio 2005 project files, explaining some small amount of trouble in getting them to work. Listmember Dirk Moerenhout notes the importance of the 2005 project files, in that the "Express" edition of the 2005 compiler is free, opening up access to developers who can't or won't spring for the Microsoft tools.

This lead to some discussion within Linden Lab about the best way to maintain 2005 projects as an ongoing concern, and one of our release engineers has created a script that scans for disparity in the files present in VS7 and VS8 projects, noting "Extending this to cover XCode and SCons files should be doable as well." In the interim, until the 2005 process is smoothed out, Brian O'Sullivan (Linden) confirmed on-list that Linden Lab would gladly accept VS2005 project patches. Nicholas posted a set at {{JIRA|VWR-1151}}, which Brian has assigned to himself. The first set had conflicts with other work, but Nicholas has posted a newer set.

Of note, for the curious, we still use 2003 as the primary platform internally, but are pushing to erase the last restrictions preventing our using 2005.

== Data Alignment ==
Dana Fagerstrom previously noted success in creating a Solaris build of the viewer on x86 and he's now doing the same for SPARC. One issue Dana runs across while working on the SPARC port are buffers that get created as U8's and are then cast as U32's, etc. Dana requests that developers consider adding explicit alignment. For now, Dana's making a patch set with the alignment #ifdef'ed for SPARC so that Lindens can consider whether the change should be made uniformly.

A global buffer with explicit alignment looks like this: 
U8 mData[UUID_BYTES] __attribute__ ((aligned(8)));

Of course the above could cause concern because the #define UUID_BYTES, which is 8, can not be used in the <CODE>aligned</CODE> attribute. However, there are only a few of these globals that need such alignment so at the moment they are workable.

A dynamic allocation of a U8 buffer of <CODE>size</CODE> bytes with word boundary alignment looks like this: 
U8* mBuffer = (U8 *)(new U32[size/4]);

Each of the above ensures that the data is aligned properly and is portable across CPU architectures.

== Please Use .txt File Extensions in JIRA ==
Dzonatas Sol suggests that text-based attachments carry a .txt file extension in JIRA. The rationale is that JIRA doesn't add a MIME type, preventing users from viewing the attachment within the browser without the file extension as a type hint.

== Email to Objects Broken ==
Kamilion pointed out that scripts were not receiving email from outside the secondlife.com domain, posting a sample script. This lead to a lengthy discussion about past unreliability in the XMLRPC and mail systems, with some speculation about how reliability could be improved. Kelly Washington (Linden) posted some details about the various communication methods available, noting that llHTTPRequest is the simplest and most reliable of the communication methods. Kelly also noted that Linden Lab were investigating the issue, and Kamilion confirmed that he'd heard back from James Linden, and that Don Linden was leading a recovery effort. Chance Unknown confirmed that some very old messages - as old as 2 weeks - were now coming through.

Any further observations about delays or breakage would be appreciated!

== Another Call for CPU Statistics ==
In the context of a thread about CPU optimization and what programmatic and manual optimizations might help and hurt different platforms, Dirk Moerenhout made a renewed call for statistics about what kinds of CPUs are in use by Second Life residents. To date, there hasn't been a posting of this information, however Laurent Laborde posted a link to a [http://www.steampowered.com/status/survey.html hardware survey] from Valve, makers of Half Life.

== Dead Flag ==
Max Okumoto noted that the LL_USE_KDU flag wasn't actually used in the viewer, and Phoenix Linden confirmed that it had now been removed internally. Thanks for pointing that out, Max.

== LLMuteList::loadFormFile() Parses the Mute List Improperly ==
Able Whitman found a discrepancy between how the mute list was formatted and how it was parsed. Brian O'Sullivan (Linden) confirmed the discrepancy and fixed the parsing internally. Nicholaz Beresford gave kudos for a nice catch - agreed!

== Sculpted Prims - .OBJ Import ==
Dzonatas Sol posted a basic .OBJ importer. .OBJ files are a common 3D mesh format, and Dzonatas' importer can handle 64x63 sphere meshes "made with Wings3D, or other modelerst hat can create such meshes." Qarl Linden expressed concern about the importer, as it would only work with very specifically formatted meshes. Periapse Linden suggested that Linden Lab should provide more details on what would make the patch usable at Dzonatas' offer to further tailor the code.

== Particle Appearance Changed ==
Argent Stonecutter noted that the appearance of particles had changed in the 1.17 viewer. Nicholaz Beresford didn't see any relevant changes in a comparison of the old and new partsim and partsource.

Argent reported progress in working with Farallon: 
The problem is that if you have "PSYS_PART_FOLLOW_SRC_MASK" then
"PSYS_SRC_BURST_RADIUS" is ignored... you can't create a particle
system that uses "PSYS_PART_FOLLOW_SRC_MASK" and starts the particle
emission at a distance. Why not, I don't know, it's always been an
annoyance to me, but I'd just gotten used to it. Farallon had some
particle systems he'd modified that had a non-zero radius set, and he
hadn't zeroed them out...

Before 1.15 or so, it acted as if "PSYS_SRC_BURST_RADIUS" was zero.

Now it seems to create the particles at "PSYS_SRC_BURST_RADIUS" then
applies the "PSYS_PART_FOLLOW_SRC_MASK" rule on the following frame.

The correct "fix" is uncertain.

Nicholaz pointed to a related JIRA at {{JIRA|VWR-1154}}, which is as-of-yet unresolved. Discussion continues about whether to support the old misuse of the system, or to break content by making the particle system work as designed and described in the documentation.

== Lex and Yacc Gurury ==
Soft Linden investigated {{JIRA|VWR-68}}, which was designed to fold some constant expressions in LSL and fix a problem where a subtraction expression could be swallowed as a negative number, creating a nonsense pair of tokens. Soft noted a case where constants could be folded improperly and asked for suggestions on a fix. Dzonatas Sol offered some input, and Argent Stonecutter, author of the original patch, offered a follow-up. Soft has promised to test and import the result.

== Bug Triage ==
This is a reminder that Rob Lanphier (Linden) holds bug triage sessions on Mondays. This is a perfect opportunity to weigh in on JIRA issues that need attention, or that may proscribe fixes you disagree with.

The agenda can always be found [https://wiki.secondlife.com/wiki/Bug_triage/Agenda on the wiki], and volunteers, including Dzonatas Sol and Gigs taggart have been doing a fantastic job of keeping the agenda up to date!

== 1.17 PJIRA Cleanup ==
Dzonatas Sol also volunteered to do some maintenance on the public JIRA following the 1.17 release. I love y'all so much. :)

SLDev-Traffic 16

2007-06-19T12:24:13Z

Whoops Babii: /* Data Alignment */

{{SLDevTraffic}}

sldev-traffic no 16

sldev discussions through June 15, 2007

== "About Land" Floater Patch ==
Zi Ree offered a patch, attached to {{JIRA|VWR-1140}}, which makes the About Land floater resizable, citing problems with some widgets, such as the ban list, being far too small. There wasn't follow-up on-list, but Zi's patch was accepted and applied. Thanks, Zi!

== Visual Studio 2005 (VS8) Project Files ==
Nicholas Beresford posted a set of up-to-date Visual Studio 2005 project files, explaining some small amount of trouble in getting them to work. Listmember Dirk Moerenhout notes the importance of the 2005 project files, in that the "Express" edition of the 2005 compiler is free, opening up access to developers who can't or won't spring for the Microsoft tools.

This lead to some discussion within Linden Lab about the best way to maintain 2005 projects as an ongoing concern, and one of our release engineers has created a script that scans for disparity in the files present in VS7 and VS8 projects, noting "Extending this to cover XCode and SCons files should be doable as well." In the interim, until the 2005 process is smoothed out, Brian O'Sullivan (Linden) confirmed on-list that Linden Lab would gladly accept VS2005 project patches. Nicholas posted a set at {{JIRA|VWR-1151}}, which Brian has assigned to himself. The first set had conflicts with other work, but Nicholas has posted a newer set.

Of note, for the curious, we still use 2003 as the primary platform internally, but are pushing to erase the last restrictions preventing our using 2005.

== Data Alignment ==
Dana Fagerstrom previously noted success in creating a Solaris build of the viewer on x86 and he's now doing the same for SPARC. One issue Dana runs across while working on the SPARC port are buffers that get created as U8's and are then cast as U32's, etc. Dana requests that developers consider adding explicit alignment. For now, Dana's making a patch set with the alignment #ifdef'ed for SPARC so that Lindens can consider whether the change should be made uniformly.

A global buffer with explicit alignment looks like this: 
U8 mData[UUID_BYTES] __attribute__ ((aligned(8)));

Of course the above could cause concern because the #define UUID_BYTES, which is 8, can not be used in the <CODE>aligned</CODE> attribute. However, there are only a few of these globals that need such alignment for at the moment they are workable.

And a dynamic allocation of a U8 buffer of <CODE>size</CODE> bytes with word boundary alignment looks like this: 
U8* mBuffer = (U8 *)(new U32[size/4]);

Each of the above ensures that the data is aligned properly and is portable across CPU architectures.

== Please Use .txt File Extensions in JIRA ==
Dzonatas Sol suggests that text-based attachments carry a .txt file extension in JIRA. The rationale is that JIRA doesn't add a MIME type, preventing users from viewing the attachment within the browser without the file extension as a type hint.

== Email to Objects Broken ==
Kamilion pointed out that scripts were not receiving email from outside the secondlife.com domain, posting a sample script. This lead to a lengthy discussion about past unreliability in the XMLRPC and mail systems, with some speculation about how reliability could be improved. Kelly Washington (Linden) posted some details about the various communication methods available, noting that llHTTPRequest is the simplest and most reliable of the communication methods. Kelly also noted that Linden Lab were investigating the issue, and Kamilion confirmed that he'd heard back from James Linden, and that Don Linden was leading a recovery effort. Chance Unknown confirmed that some very old messages - as old as 2 weeks - were now coming through.

Any further observations about delays or breakage would be appreciated!

== Another Call for CPU Statistics ==
In the context of a thread about CPU optimization and what programmatic and manual optimizations might help and hurt different platforms, Dirk Moerenhout made a renewed call for statistics about what kinds of CPUs are in use by Second Life residents. To date, there hasn't been a posting of this information, however Laurent Laborde posted a link to a [http://www.steampowered.com/status/survey.html hardware survey] from Valve, makers of Half Life.

== Dead Flag ==
Max Okumoto noted that the LL_USE_KDU flag wasn't actually used in the viewer, and Phoenix Linden confirmed that it had now been removed internally. Thanks for pointing that out, Max.

== LLMuteList::loadFormFile() Parses the Mute List Improperly ==
Able Whitman found a discrepancy between how the mute list was formatted and how it was parsed. Brian O'Sullivan (Linden) confirmed the discrepancy and fixed the parsing internally. Nicholaz Beresford gave kudos for a nice catch - agreed!

== Sculpted Prims - .OBJ Import ==
Dzonatas Sol posted a basic .OBJ importer. .OBJ files are a common 3D mesh format, and Dzonatas' importer can handle 64x63 sphere meshes "made with Wings3D, or other modelerst hat can create such meshes." Qarl Linden expressed concern about the importer, as it would only work with very specifically formatted meshes. Periapse Linden suggested that Linden Lab should provide more details on what would make the patch usable at Dzonatas' offer to further tailor the code.

== Particle Appearance Changed ==
Argent Stonecutter noted that the appearance of particles had changed in the 1.17 viewer. Nicholaz Beresford didn't see any relevant changes in a comparison of the old and new partsim and partsource.

Argent reported progress in working with Farallon: 
The problem is that if you have "PSYS_PART_FOLLOW_SRC_MASK" then
"PSYS_SRC_BURST_RADIUS" is ignored... you can't create a particle
system that uses "PSYS_PART_FOLLOW_SRC_MASK" and starts the particle
emission at a distance. Why not, I don't know, it's always been an
annoyance to me, but I'd just gotten used to it. Farallon had some
particle systems he'd modified that had a non-zero radius set, and he
hadn't zeroed them out...

Before 1.15 or so, it acted as if "PSYS_SRC_BURST_RADIUS" was zero.

Now it seems to create the particles at "PSYS_SRC_BURST_RADIUS" then
applies the "PSYS_PART_FOLLOW_SRC_MASK" rule on the following frame.

The correct "fix" is uncertain.

Nicholaz pointed to a related JIRA at {{JIRA|VWR-1154}}, which is as-of-yet unresolved. Discussion continues about whether to support the old misuse of the system, or to break content by making the particle system work as designed and described in the documentation.

== Lex and Yacc Gurury ==
Soft Linden investigated {{JIRA|VWR-68}}, which was designed to fold some constant expressions in LSL and fix a problem where a subtraction expression could be swallowed as a negative number, creating a nonsense pair of tokens. Soft noted a case where constants could be folded improperly and asked for suggestions on a fix. Dzonatas Sol offered some input, and Argent Stonecutter, author of the original patch, offered a follow-up. Soft has promised to test and import the result.

== Bug Triage ==
This is a reminder that Rob Lanphier (Linden) holds bug triage sessions on Mondays. This is a perfect opportunity to weigh in on JIRA issues that need attention, or that may proscribe fixes you disagree with.

The agenda can always be found [https://wiki.secondlife.com/wiki/Bug_triage/Agenda on the wiki], and volunteers, including Dzonatas Sol and Gigs taggart have been doing a fantastic job of keeping the agenda up to date!

== 1.17 PJIRA Cleanup ==
Dzonatas Sol also volunteered to do some maintenance on the public JIRA following the 1.17 release. I love y'all so much. :)