Jump to content

Gavin Hird

Resident
  • Content Count

    1,303
  • Joined

  • Last visited

Everything posted by Gavin Hird

  1. Why is it that you don't handle EU and European Economic Area citizens through your UK Tilia subsidiary when the GDPR regulation states you must do so? GDPR is a regulation meaning no implementation is required in national law for a regulation, as it is of direct application. The legal rules it creates are, depending on its subjects, directly applicable to any entity on the territory of the European Union and European Economic Area. Any citizen will be able to refer to the GDPR provisions after May 25th 2018, and its provisions will be directly enforceable by any court. This implies that any EU and European Economic Area citizen who is a customer of Linden Labs and its subsidiaries have the right to take the Tilia UK subsidiary to court in Europe for failure to implement the GDRP. The same right can be extended to general consumer protection, banking and financials sector regulations and tax regulations. While you have a US requirement to do IRS reporting on US citizens and US registered businesses, there is absolutely no point in reporting transactions for non US citizens or companies to the IRS where in many cases these might risk IRS tax withholding. This can completely be avoided - at least for European Union and European Economic Area entities by establishing a relation between these and your UK subsidiary, and not your US registered company as you have set forth in this communication. Then the UK subsidiary would have to do their tax reporting in accordance with EU regulations to the member state for the entity in question (person or business). The "disadvantage" perhaps from your perspective is that the UK company would have to be in full compliance with all EU regulations. The upside is that you will avoid the often significant noise your terms creates with European Union and European Economic Area customers, and consumers in particular. Being in compliance would easier persuade these you are a company that can be trusted with their business.
  2. It is hard to say exactly how Brexit will pan out in this respect, but many companies will have to register subsidiaries inside the EU to ensure they can make business with the EU market, which without the UK is 455 million (now 511 million with the UK). Europe overall is about 758 million. Having said that, UK legislation is more or less harmonized with the rest of the EU on the issues discussed, and will continue to be so unless the UK parliament change them to something else post Brexit.
  3. The problem presented for you in regards to EU citizens is that you have established a subsidiary; Tilia Branch UK Ltd, which is established inside the European Union / European Economic Area, and therefore make you 100% required to comply with EU legislation when it comes to privacy, consumer legislation, the GDPR directive and conflict resolution. As a matter of fact, since you have this subsidiary inside the EU, you HAVE to handle your European Union / European Economic Area customers through this company, in the same manner as i.e. Apple, Microsoft, PayPal HAVE to handle their customer relationships through their European subsidiaries and not the US mother company. So for European Union / European Economic Area customers you have to present terms of service, requirements for identification, handling of privacy and conflict resolution according to EU law. These will necessarily be different, in the same manner as we see it for the aforementioned companies, from what is presented to the US citizens. I am of the opinion the terms, as currently presented, does not meet the minimum requirements for a B2C contract based on EU law. It is in your interest to make them meet these requirements, or the minimum requirements will be applied by the courts in Europe and you will lose in conflicts. In a conflict with a European Union / European Economic Area citizen or company, it is the Tilia Branch UK Ltd company that will be taken to court, and EU law will be applied. Granted some of the entities who will deal with Tilia will be businesses and for them you can present a completely different set of terms and contracts, but the majority of Secondlife customers are consumers (the definition also exist in EU law). You also have to follow EU tax legislation for these customers, and there is no reason why you should report European Union / European Economic Area customers being private or businesses to the IRS. It shall be reported to the EU member states in question from your Tilia Branch UK Ltd company.
  4. Exactly. Or they could share the username and the hashed password (which cannot be decrypted).
  5. Asking non US citizens to resolve Disputes in the US is the same as telling them they cannot resolve disputes at all, as it is not practical or economical. For EU citizens, their UK subsidiary will be the contract party (as long as they are in the EU and Brexit has not been resolved), and obviously disputes will have to be done in a EU court.
  6. I could not see a single line about GDPR Compliance in the terms and privacy policies for this Tilia company? Since we are asked to provide government issued identification if non US citizens, the company we give it to must be in GDPR compliance when handling EU citizens of which there are quite a few of in Secondlife.
  7. OpenGL will most likely be gone in 10.16 if you read between the lines of the OpenGL to Metal conversion session of WWDC 2019. I also found the viewer is running fine in the macOS 10.15 beta, but the HIToolbox is still present in it, and Apple said very explicitly in last years WWDC that HIToolbox will be gone for good in 10.15. It is still early days, so we shall see...
  8. LOL I have not been in the market for a rendering engineer, preferably with Metal experience. Linden Lab has!
  9. Mavericks is 10.9 and there was no Metal till 10.11. 10.11 is when the crashes started, and this is when the NSOpenGLProfileVersionLegacystarted to be enforced strict. So what you reported for Mavericks is pretty much irrelevant. ;-)
  10. The NVIDIA driver does not support Metal, which is the reason why users will see a significant reduction in system frame rates over using the Apple driver on macOS 10.11 and 10.12. More importantly, the NVIDIA driver does not impose the restrictions of the Apple NSOpenGLProfileVersionLegacy where before Metal it was possible to call the OpenGL functions supported by the hardware directly, whereas after Metal in macOS 10.11 you can't do that any more with the Apple driver. This is why the code started to fail in 10.11.
  11. As opposed to you Cinder, I have an open acknowledged bug report with Apple Software Engineering on the subject and it is NOT the driver, it is the Linden code that is not being updated for deprecated functionality.
  12. No, they do not. Stop spreading misinformation Whirly! The crashes occur in the Linden code beaches it is using OpenGL extensions not available not the OpenGL 2.1 profile all viewers (including Firestorm) use on macOS. So it tries to write to GPU memory illegally, causing a GPU MMU reset. The good thing is that in out testing of Kokua and KokuaOS, these are significantly more stable on macOS 10.12.4. The same is the case with the SecondLife official viewer. The other viewers tested still crash or have strange mesh artifacting. I have sent an large number of stack traces to Apple the last year, and it seems they have been able to eliminate some of the conditions leading up to the crash, but in busy scenes the viewers will crash as before.
  13. There is a development build for the macOS version of Kokua at my Bitbucket that many find more stable than other viewers. It does not have Jelly Dolls and Bento, but otherwise it should work in SecondLife for now. If you have 512 Mb or less GPU memory, lowering this to 384 in the grapichs settings often increase stability. Also this version will crash in scenes with lots of mesh and many avatars, particularly with shadows and ambient occlusion turned on. These builds are signed with my Apple developer ID so you know where they come from.
  14. ChinRey wrote: LinuxGod4u wrote: That is a useful post. Are Mac Os(s) anything like Linux?? A good question and not easy to answer. Mac OS X is based on FreeBSD which of course is very similar but not identical to Linux. So there are many similarities but also significant differences. No it is not based on FreeBSD. It has a BSD subsystem that originally was based on FreeBSD, but was certified as Unix 03 later. The Mach kernel, the IO system, the Frameworks, the UI and development tools, including Swift are not Linux like at all. When the viewer was originally started, this was more true, and is what the viewer code is largely still stuck in making it increasingly incompatible for each version of macOS.
  15. Hi Thanks! Usually we have test builds every week and sometime more frequent depending on how big changes are. Right now we have a Bento Test build. If you want to file tickets and comment on them, you would have to create a user on SourceForge. It is not entirely unlikely there will be a JIRA from the beginning of 2017.
  16. We have another round of builds for the Kokua viewer that in our own testing lowers GPU reset rates from "will crash within 5 minutes" to "no crash in 2 1/2 hours" in the same test scene. Obviously we don't have a large selection of Apple hardware to test on so YMMW, but we encourage you to test the new builds. For these builds we also find that if you have 512 Mb or less graphics memory in your machine you will get a more stable system by setting the texture memory slider to 384 Mb in Graphcis Advanced preferences (Advanced - Hardware for OpenSim). You get the SecondLife version and the OpenSim version from SourceForge. NOTE, the GPU will still be reset under certain conditions, but this cannot be fixed unless the renderer is rewritten to support OpenGL 3.2.
  17. There are now SecondLife version builds of the Kokua viewer at Sourceforge that have the same code changes as the OpenSim version. This version should have the same functionality as the latest Linden release version. (most recent uploads) These versions should work better on macOS 10.11 and 10.12. As stated before they will crash the GPU in some scenes so ymmw.
  18. I am glad it improved the situation for you. We shall have to update the SecondLife version of Kokua too. Cheers!
  19. It is one of the dmg files at the top. (with and without RLV support). It is hard to say eactly why there is no priority of fixing the Mac version of the viewer, as in many ways the code it is made up of have rotted on root void of all the changes Apple have gone through since leaving the GCC compiler behind 6 major macOS versions back. Most of this time I have been an observer, rather than an active contributor to a Mac version of the viewer, but my major observation is there is an inbred disdain of anything Apple both in Linden Lab, which also extends to the much larger section of the user base and developers.
  20. Whirly Fizzle wrote: If you are using the Nvidia web drivers though, you won't crash. The crash only happens if the system is using the Apple Nvidia drivers. You can use the NVIDIA drivers, but they are both a bit hard to find, and tied to a specific macOS build so they break at just about every update. They are only meant for the Mac Pro, but they happen to work on other machines too. Here is a link to a site that maintains links to the drivers. Make sure you download the one for the macOS build number (can be easiest found from the System Report function linked to "About This Mac" on the Apple menu. This is, however, only a stopgap, and no excuse for LL not to fix the viewer code (that 25% of their contet developers relies on in one for or another.)
  21. No,it is not viewer specific, but GPU specific. As far as I know the Radeon GPUs are not affected like the NVIDIA ones. – Which is why your iMac is good. The crash is more pronounced on macOS 10.12 than on 10.11. Per my findings the crash on 10.11 occurs in the culling code; the code that caclulates what part of the scene is visible and shall be rendered. It manifest itself in scenes with medium to high content of mesh items when shadows are turned on. On 10.12 in addition the code that calculates ambient occlusion will crash the viewer, and this can be provoked by only turning ambient occlusion on. There is a jira for the crash, but as far as I know nothing have been done but acknowledge the fact. More important Apple Engineering has been able to repro the crash on the SecondLife viewer with the OpenGL 2.1 profile that the Mac version of all viewers use. To fix it, the Mac version must use a OpenGL 3.2 profile for the renderer as a minimum (and be made Metal aware). We have a development version of Kokua for OpenSim where the ambient occlusion issue is partly squashed. You can still log on to SecondLife with this version of the viewer.
  22. Krystal Iridescent wrote: I am surprised that nobody has recommended Alchemy Viewer yet? I have run it for at least two years on my Macbook Pro mid 2012 model and now that I updated to Sierra, it is still by far the best viewer to use. Depeding on your Macbook Pro model it may only have Intel graphics, and is therefore not affected. Macs with descrete grapichs (and some of them also have Intel graphics in addition) will also crash the Alcmehy viewer in the same manner as the other viewers. Turning on Ambient Occlusion will crash the viewer as the crash happens in the occlusion code overwriting memory in the GPU leading to a GPU reset. Turning on shadows will accomplish the same, but usually faster the busier the scene is.
  23. Bitsy Buccaneer wrote: Any advice on what to do? I'd really rather not lose SL, but this isn't a great time to buy a new computer and I have absolutely no reason to other than SL. Am feeling rather lost and stressed about it. The only thing you currently can do is lower your graphics settings to a point where the viewer is stable. You may want to make different presets for different areas you are in, so you can easily switch between them. One setting may work in your home, but will crash the GPU (and the viewer) if you go to a mesh heavy area, or a crowded club. Depending on how much graphics memory yopur Mac has, you may also experiment with the texture memory slider. The setting should be preserved as part of a preset. I am sorry for all the Mac users who feel this pain right now.
  24. For every iteration of macOS the rendering code in the Mac version of any viewer gets more and more incompatible with macOS, because Linden Lab does nothing to update the very outdated code that exist in the macOS version of the LL viewer. The same code is use by every third party viewer. The reason why the NVIDIA driver also gets more outdated / hard to update is that Apple is replacing more and more funtionality of the graphics drivers with their own METAL code, at the expense of OpenGL, which they have not updated for quite some time. So unless Linden Lab manage to write a METAL renderer, it will most likely continue to get worse. They are in the market for a rendering engineer, preferably with METAL experience, but I don't know if the position has been filled. Such a person is most likely very expensive to hire. I can show you exactly where in the code the viewers will crash, and why you have to turn off occlusion / shadows for the viewer to be stable (I am the maintainer of the Mac version of the Kokua viewer.) I am not in a position to be able to rewrite the renderer, however.
  25. DeeKate wrote: Does this mean that I can take a (possibly long) leave from SL? It does not mean you have to elave SL, but you probably have to turn off shadows, in combination with reducing draw distance and lowering mesh quality in the Graphics Preferences tab. It will take a bit of trial and error to figure out what works best with your computer. Having shadwos turned on will crash your viewer at some point.
×
×
  • Create New...