WolfBaginski Bearsfoot

I have maybe escaped some of the problems because I set up my Paypal account a long time ago, used it for selling some stuff on eBay.. It's linked to my bank account. and so I transfer money to Paypal using my bank's internet banking service. And then Paypal to Linden Labs is easy. You can pay your Premium membership by this route, but Linden Labs insist on your credit card being set up for this as a default, and that's where things seem messy. There's something odd about the way all this has happened. It won't be the first time that Linden Labs has seemed to ignore their own rules on changing the TOS. But why? Has there been some massive security breach? Or is it an ultimatum from the US government? Naybe there is a reason to not disclose the security problem, but I can't see why, if this is the effect of some new legal requirement, that must stay silent. Is it incompetent comminication, or some massive fraud?

Firestorm worked for me, but it was horribly slow. I think we may have found an element of the Lindern server system that is prone to falling over under load.

I'm not aware of any official statement that this is the result of a change in the banking regulation of the USA. Something of that sort has happened, around 6 weeks ago, but nothing has been said by Linden Labs about a change in the law. They did attribute the ban on gambling to legal issues. And the TOS does specify a 30-day notice period. If the lawyers were recommending an immediate half it's a bit odd that they doin't seem to have used that as a resaon to break their own rules. All we have is guess work. Is it the law, or is it some scheme to pick up a million dollars in fees? Do the Lindens really appreciate that they have customers outside the USA? The merchants have been complaining about Linden incompetence for the last year or so. The Marketplace has problems, and the Lindens charge transaction fees without taking any responsibility for such things as failures to deliver. In the end, the spiel about the TPEs being more susceptible to fraud does not hold up. Most of them are in Europe, operating under European standards on card payment and money laundering.

A lot of this looks like the usual Linden incompetences, starting with inept customer communication. The website operation is less than stellar, and the payment systems are worse than the usual I see from US web retailers. Last year, the biggest of the third-party exchanges turned over the equivalent of 38 million dollars. The fees, and the Buy-Sell spread, on the LindeX would be a very useful bit of extra income. I really cannot see why they cannot follow their own 30-day rule on changes to the TOS.

I know that the card payment system in Europe is more secure than in the USA. A payment to a TPE in Europe is less likely to be fraudulent than a payment made direct to Linden Lans, simply because it goes through the US system which doesn't use certain checks. For instance, there is an authentication password which the card network asks for to authorize a payment in Europe. The authentication exchanges in the US system do not hook into that. On what I have seen, the TPEs charge less, in fixed fees and from the spread between Buy and Sell, than the Lindex does. Also the relationship between the L$ amount and the real-currency amount is clear, because they quote prices in other currencies than the USD. The advantages of LindeX trading that the blog post claims are illusory. When you figure in exchange costs, a TPE only has to buy or sell USD to cover the net trade in L$. Most transactions will be in their local currency. User A will buy L$, and the money they pay will go to user B who is selling them. And the TPE has to keep records. Their country will have tax systems, and accountants, and laws against money-laundering. The assertions in the blog post suggest that Linden Labs doesn't quite realise that they are a business with customers outside the USA. Heck, they might not quite understand that they have customers in Nevada.

There are probably some differences in the requirements for handling card payments between the US and Europe. There are options used here which I have never seen used by US companies. Does that mean the USA is less secure? I don't know. But I have done business with US companies, and seen how their handling of the card payment process works, and judged by that experience, Linden Labs is not well run. A Europe-based alternative exchange with clear starements of the real-world payment I would make and the L$ I would receive before I clicked the button, and operating with the European levels of security checks, looks enormously more reliable than the LindeX. It makes the blog-post claims about being the safer option look rather hollow. And if the TOS fancy-footwork about Linden Dollars being really valueless licences/tokens can't fend off the US government, why bother trying? The way Linden Research is willing to deny all responsibility for supply of the services we think we are paying for. it just feels wrong. They're lucky they're subject to US law: most of the TOS would be unenforceable in Europe.

One source of income for LL is the difference between Buy and Sell rates on the Lindex. They don't get that income from the third-party exchanges.

As usual, we just have to wait for godot Linden to turn up with the full explanation.

Don't worry about Mesh clothing. Most people are still using the original texture-based system. And there is viewer tech in the works which will change the game again when it gets released. Today's Mesh may be onsolete very soon. Besides, I was at an event a few weekends back which asked people to wear outfits that used the SL tech of 8 years ago. The clothes looked good, and there was little or no lag. You might be able to sell on the concept of quality without lag. But check your scripts. Things such as resizers have gone from being a script in every prim to a single script for the whole linkset, because of changes to LSL.

I am not convinced that any of this does add security. I'm not sure we have less security, but LL makes no guarantee of what a L$ is worth. It's just what other residents are willing to pay. And the third-party exchanges depended on the same principle. I buy L$ from Virwox, and somebody has to have sold them to Virwox.

One of the problems for those of us outside the USA is that we have to convert between USD and our local currency, and lose out on every transaction. Some of the rates used can be seriously adrift from the exchange rate the banks can get, and we cannot easily discover it in advance. The third-party exchanges, which will accept my currency, are doing the same setting of a margin to cover their costs, and make a profit, which is why the :Lindens can say we get a better deal on the Lindex. But the chain from my bank account to Linden Labs is what matters to me, and I confess I have my doubts about some parts of that chain. The last time my Premium payment came due, the transaction failed. I got the money to Linden Labs by another route, but nobody seemed to know the reason for the failure, and a few days later I got a letter from my bank reminding me that I should tell them before I went to the USA. Linden Labs are saying the third-party exchanges cannot be trusted any more. My experience suggests that the European banks are getting a bit wary of making payments to the USA, and we do seem to have more security measures on transactions. Instant cashout doesn't matter to me. Linden Labs doesn't get enough money from me to be worth fussing pver. But several hundred USD per month, in or out, would be enough to make me wonder how much I should trust them. Some of you guys are getting my money, and I hope you can still see real money in your bank account. Or will we all owe our souls to the company store?

The blog post uses the phrade "authorized or allowed", which has the ring of lawyer-speak to it, and I infer from it that "authorized" and "allowed" are distinct. The TOS itself doesn't use that phrase. Which seems odd. Realistically the L& is only ever worth what other people will pay for it, but now it seems that the external L$ exchanges are being given the elbow. They are not "authorized", but since Linden Research doesn't guarantee any value for the L$ I am not sure how that makes any difference. But the Wiki Page on the Exchange Risk API is dead. There's more to this than just a change to the wording of the TOS.

I shall give that a try, it sounds like it should work, for the same sorts of other reason as other fixes I have seen. Yes, this is a very old bug, and various bits of my AV have vanished in the past. It's all getting more common with interest Lists. Maybe some of the other long-standing bugs can be fixed, if we can arrnage for some new Linden shiny to exacerbate them.

But LL are always putting new code in servers.

Right now, on Main Channel, it is worse than it was before the rollout. Bad rubber-banding, even within a region, poor sim-crossing even when walking. It could be a network problem, but what a coincidence!

I think you guys may have missed a bug in the sim code that rolled out onto the main channel. Sim crossings have been getting worse and worse since then. I've been trying walking, as well as with vehicles. I've approached the border as slowly as possible. I have tried Fiorestorm, Kokua, an ancient Linden Lab viewer, and two different versions of Cool VL Viewer. None of them are loading all prims, not of them are loading textures at a speed better than sluggish. And, on two occasions, the vehicle I had been using was returned from a parcel three regions away from the boundary I had been crossing when things went wrong. I've also found a stretch of Linden Road with scripts switched off, which messes up vehicles in a whole set of new ways. What;s the point of having the road through Waterhead? And even when nothing else is going wrong, vehicle sit poses are being displaced at the first sim crossing. I didn't see any sign of this during the time the code was in the RCs. Is there a server falling over with the load from the whole Grid? I doubt any of this can be blamed on SSA, because using a non-SSA viewer didn't change anything, but if this is, in some way, a consequence of that project, it wasn't worth doing.

Sorry, I just can't resist this temptaion.

You know, it's what Oz says that worries me. This is new code in the sim servers, and it should have the same testing as any other new code: run it in an RC and see what goes wrong. Whether it goes live in the whole RC set, that's a different question. There are the servers doing the actual baking, and all the changes to network traffic as a result, and I can't see how they can have tested all that on the Beta Grid. They might have enough data to make a good guess, but can they afford not to do a slow initial roll-out? And just check what Oz says about himself. He's the Open Source guy at Linden Labs, which means the Viewer, not the Sim Servers. He needs to get the Viewer side out before the Server side can go active, and to do that he has to talk with the server-side team, but I doubt he has much to do with the server deployment plan. Oz is, I hope, working his little socks off on the Viewer side. I can imagine the server-side team making impatient noises behind the scenes. I can understand him being a bit vague about some of the details of the server deployment. He'll be watching the viewer-use figures, maybe has a percentage of SSA viewers as a target, but the servers aren't his pigeon. Or penguin. Or whatever. I'm not sure who is Oz Linden's equivalent on the server side, but they're the person I'd expect to give reliable info.

Just to add, the server-side code for SSB is apparently something they can switch on or off without a restart. So it might need an RC test, but it might not be switched-on on the whole RC. Since there's some complications with how an SSB-capable viewer responds to moving back to old-style baking, I hope they're careful about just which regions are switched on for testing. Unlike Physics, last year, this potentially messes up everyone. Also, they don't want too big a jump in the load on the servers that do the baking. I really doubt they will jump from RC to the whole grid. Weekends, in particular, could get interesting if the expend the SSB coverage too quickly. Anyhow, that's how I interpret what I've heard. The code in the sim servers ought to go through the RC process, but there are other critical elements which need careful deployment.

Thanks for the response. Since I'm the guy who mentioned caching, I figured I had better make my thinking clear. If turning off HTTP textures does make a difference, the only way I can see of a user making a useful measurement is to visit the same region twice, one with HTTP Textures off, and once with them on. And the cache will have to be cleared before each visit. Otherwise, having data cached will make the second visit, whichever option is chosen, give a faster result. I think I am awake enough for that to make sense. From what you say, there's enough complexity in the traffic, with different types of data, that very few of us will have the tools to record useful data. And besides, the internet as a whole can get pretty gnarly. In my own case, I know there are certain times of day when the internet at my end gets very busy, with other customers of my ISP streaming video. Weekdays are different from weekends, and the timing alters during school vacations. To be honest, it looks complicated enough that I sometimes feel I shall never be able to give useful hard data. I know I've sometimes managed to start something rolling. And one side thought: I've seen pics and machinima of the Fantasy Faire stuff, and the regions look wonderful, and full of wonders. But if they're intended to get people to visit and hand over their hard-earned L$, and they're generating the high server traffic levels reported, maybe something a little less fancy would have been a better design. Is it the equivalent of those hugely complex, slow to load, web pages of the past?

And now I have tried it, and it does seem to make a difference, but I'm not sure whether that might be the effect of caching or not. It's worth some more careful checking. But, since I'm running the Firestorm Preview, take what I'm seeing with a pinch of salt

Maybe obvious, but some viewers have an option to turn off HTTP Textures. Firestorm, for one. Have you tried this, (It might not actually make any difference, I know.)

Part of the problem is that the quality of old freebies is so variable. There's some well-made texture-based clothing, and some rubbish. But the good stuff hasn't been broken by changes. On the other hand, there are old freebie vehicles which are almost unusable because of the accumulated changes to physics, and some of them are otherwise quite good models. But my idea of "good" might not always match yours.

In my experience, camera zooming is not always effective. I note that the Interest List code has had a revision that suggests time could be a factor. Since it's been stated that gadgets such as the graphics-cleaning rockets should be modified to hold the AV at altitude for at least five seconds, waiting that long before zooming back seems like a good idea.

The self-cleaning nature of the cache depends on how big it is, and your pattern of using SL. I was seeing consistent prim errors in regularly visited locations. Those particular errors stopped when I cleared cache. It hasn't cured the underlying problem, and I wouldn't want to do it again any time soon, but I reckon I made a good choice, this time. I saw a positive effect. Note to Maestro: when the fix is fully deployed, I shall probably clear cache again. But that does depend on a clear statement of what changes are in the code. I don't think in terms of JIRA numbers.