Beq Talks About The Future Of Firestorm And PBR

[AnthonyJoanne]

On 6/2/2024 at 2:36 AM, Beq Janus said:

This is what I mean. The grids.xml that we distribute and host will be pruned back to nothing (just the SL grids and localhost), even picking "bigger grids" suggests some favouritism and does not stand up over time.

So, on a clean install, you'll get a nearly blank list. It will respect your locally configured grids as previously. However, you will now have the new " + click to add more grids," which pops up the grid selector. The selector list is derived from Hypergrid Business' list with Maria's permission. Over time, if OpenSim gets its act together and provides a de facto live list, then it can be easily switched. 

 

 

 

I got wildly excited there for a minute, in your original post mentioning the grid list.

I was hoping that you meant we could sort the login list by grid ... i.e. having all the toons on a given grid grouped together rather than just sorting it alphabetically.

It serves me right for having multiple avatars with the same name on multiple grids. 😛

[Cristiano Midnight]

4 hours ago, HeathcliffMontague said:

For those on more low powered machines (which I am fortunately not these days ) it can make a huge difference.

As you know, even on high end machines, SL can still often run like garbage. Every little bit helps.

[Arielle Popstar]

4 hours ago, AnthonyJoanne said:

 

I got wildly excited there for a minute, in your original post mentioning the grid list.

I was hoping that you meant we could sort the login list by grid ... i.e. having all the toons on a given grid grouped together rather than just sorting it alphabetically.

It serves me right for having multiple avatars with the same name on multiple grids. 😛

There used to be such an external Grid manager app that would allow one to pick the account, the grid desired and even select which viewer.

[Beq Janus]

I think the "why do I need to whitelist?" question has been adequately answered already but to summarise. 

Your AV is designed to protect you from malicious files, it does this by running a scan on new files as and when they appear. It your cache folder is not whitelisted then you AV will happily burn your CPU and your disk IO continually scanning and rescanning files as they appear. Because there are so many different AVs and even within those different versions and options the impact can vary from one person to the next, The impact that I noticed (and that surprised even me) was that my textures were getting stuck on a low resolution. I was hunting for a bug that seemed to explain when I found that the AV was not whitelisted (because I'd been deliberately mesing with my cache locations). This may have been due to the cache not being whitelisted or to the realtime scanning and not having the exe listed (though I think it was).

Why don't I have to do it to other apps?

As was mentioned, other apps are almost certainly not writing and rewriting the cache files, and/or do not have a performance critical dependency on accessing them. 

Whitelisting the binaries

The executables, the code itself, have other limitations applied. Certain AVs will limit what network access and other resources a program can have access to. In addition, AV software that does realtime scanning, can inject itself in between your viewer and the internet and inspects every byte passing through, this used to cause absolute chaos as it would disable certain streaming features. I've not explored that area lately to know if it is still the case, I have no reason to think otherwise.

Signed binaries

We do not sign any binaries except for Mac (where there is no choice). Digitally signed binaries might help a little. They definitely help on the installation by not making you click the "Run anyway" prompt. We used to sign them, but it stopped shortly after I joined the team, IIRC. There were two reasons: cost and anonymity. the certificates required to sign releases are not free as a rule, but they are not super expensive (a few hundred pounds per platform per year); the bigger issue was that back then, signing required that the RL name of the specific developer who was producing the builds be public, and that was not something anyone had any interest in. It also meant that team changes required new certs and a whole heap of complexity.

I have been researching a couple of options that might allow us to sign builds now that we are in the cloud without the doxxing and without the costs. It is on the TODO list, but there are only 24 hours in a day, and FS work has to take its ration of them.

Signed binaries would not (I think) remove the need to whitelist. AV still scans the folders by default. It would increase the base level of trust that the AV software gives us and that might help a bit. Mostly it will just reduce the support pain when a new release appears.

 

 

 

[Perrie Juran]

I didn't whitelist for many years.

One day I log in and many media related things did not work.

Following Firestorm's trouble shooting I checked Task Manager and there were no instances of Dullahan Host running.

Out of the blue my  anti virus had randomly decided to  kill  Dullahan.

[Arielle Popstar]

It seemed to me that dullahan was crashing on my system but it didn't seem to effect anything for me so I didn't worry about it.