arabellajones

If you use a third-party email system, not linked to your ISP or provided by your employer, it's quite likely that emails sent to you pass through a spam filtering system, and anything that uses email as an identity check has to get past such filtering. This uses what they call AI, and the systems aren't really intelligent. The genuine identity checks are sending you a link in an email, which you click on, and that's just what the spammers are trying to get you to do. I'm familiar with Gmail, but the basic idea doesn't change. Something suspicious arrives, and it gets put in a Spam folder, and that's a place you can check. But what do you do then? That's where it can get geeky. It really helps to know how such things as email headers work. But when you're expecting an identity-check email it's likely to be arriving at a particular time and giving a link to a known place. But what is really important is that you can tell the system that an email in "not-spam", and that gets fed into the AI system. I just had to do this for my ISP billing notice. The system isn't perfect, but it can't be, and they have to provide work-arounds.

I have now upgraded to Linux Mint v21. It's working OK. I could have waited longer.

It would be sort of nice if you managed to post this before the scheduled activity started.

This may still be pushing the limits of the content rules. Linux Mint v21 has been released. This is not something trivial, not something easy, and I feel no urge to rush into it myself, but it is there. Linux Mint is one of the more popular distributions, derived in turn from Ubuntu, but I shall do a bit of wait-and-see.

I am putting this link here to the official Linux Mint instructions for upgrading from Mint 19.3 to Mint 20 This is not a simple process, there is much done on the command line, and it takes several hours. You need to be pretty sure of your Linux system-admin skills. But support for Linux Mint 19.3 ends in 2023 so it is, I think, time to start developing the skills needed. You may be surprised how many places there are where you can learn the skills. It's a different distribution, but The Raspberry Pi organisation publishes a lot of Linux basics, and this is a useful starting point This particular book about the command-line is what the Raspberry Pi people are teaching schoolkids. I am probably pushing the limits of the formal wording of the content rules for this forum, so I shall stop here, but this is one of the sources I used for developing my own Linux skills.

Linux Mint has a "Display Manager" tool which lists several driver options. It's available through the menu system and from the Welcome app. I ran the v470 driver for a long time. It's about as low-geek as you can get for changing video drivers. I eventually switched to the v510 driver which is definitely faster, and your video card is faster hardware than mine. Display Manager now includes the latest nVidia version as an option on my system, but that may reflect some of the things I did since May.

My Linux Mint system has upgraded to v515.65 which appears to be an automatic upgrade from the v515.57 that fixed the bug affecting OpenGL software such as Second Life. There has not yet been a change to the v516.59 for Windows, which was released at the end of June, fixing the same OpenGL bug Please take note of the different version numbers for Unix-class systems and for Windows. I know most of us use Windows, but when the OpenGL bug popped up, pretty much all the commentators talked about the Windows version number as if it were the only one affected. This new Linux version arrived on my system through the Ubuntu chain, which avoids some of the possible problems with an install of a direct download from nVidia. As usual, take care. There may be a Windows driver upgrade close to being released.

The completion massage on Status is timestamped 14:34 PDT. Who can I trust?

There's a new release of Firestorm, came out Monday. I don't know if it makes any difference. I haven't tried it yet. Since the Linden Lab viewer does have a MacOS version that would be worth trying. If the mic works with that you have something that justifies a JIRA for Firestorm. I am not much impressed by the submit-a-JIRA meme, it often seems to be a sign that the programming geeks have problems reading clear English.

There's a problem with the direct-from-Nvidia Linux versions if you're using sleep/hibernate options. There can be resume problems on some distributions. This fix gets put out on various "help" sites. This is the link to the original Nvidia instructions, but the "why" of the problem may not be reliable. If you're using an Nvidia-sourced driver, you may still need to apply this fix. It references v470, which is seriously old, but I have seen the problems with v515. The fix still works. Nvidia fix for suspend/hibernate problems This seems to be the original source for the particular fix, and it isn't getting clear credit. I have not experienced the problem with any driver upgrade that has come through the normal distribution upgrade channel.

I have been looking over the options on caching, and as a Linux user there are several system defaults which come into play. Caching in RAM may not be so helpful. The RAM not specifically allocated is used for write caching for all disks, and I certainly don't have an internet connection that comes close to what Henri has. My internet connection speed would max out long before SSD write speed. I did a few tests, and I do have enough RAM, but the ramdisk solutions I can find all seem rather elderly, or specific to high-bandwidth server systems.

You do have a lot of RAM in your system. I would have to think hard about that option. I have a good-quality SSD as a spare, but a RAM disk may not be a viable option for me. I suppose I could drop the total cache size, but my system is, in some ways, rather old. A RAM disk seems more to be something to budget for in a new, current, system.

I can now confirm that the entries in /etc/fstab have fixed things. The instructions are nearly five years old, and I urge you to check the man page for fstab. You are now strongly recommended to used the UUID to reference the drive, as the mount point can change. This can be copied from /etc/mtab /dev/sda1 / ext4 rw,relatime,errors=remount-ro 0 0 It's preferred now to use this form. The UUID is drawn from the physical drive hardware, and doesn't change. Other identifiers can change: unlikely but there are no guarantees. UUID=6cd980aa-9eda-4021-84dc-174155175022 / ext4 errors=remount-ro 0 1 It is also possible to use a Partition UUID, "PARTUUID", a more specific location. The blkid command lists the UUIDs active on your machine, and you can copy-and-paste from a terminal window to whatever editor you use. I knew I was having this problem with another drive, USB-connected, and I kept dead-ending with the very obvious idea of checking the drive was active in a shell script. This is an instance of the solution hitting the problem from a non-obvious direction. The SSD gave the same problem with an internal SATA connection. How it ended up classed as removable I have no idea. Every drive is removable, with the right screwdriver.

That's set to the maximum. If you have the space, even on a spinning metal drive, and modern disk drives are pretty big, you might as well use it.I usually run with a 32m draw distance—it's the range for talking—but Firestorm makes it easy to change as that is a bit short for driving vehicles.

Thanks, I had a couple of drives showing similar behaviour. Had to use blkid to get the UUID, but no big problems. Haven't tested Firestorm yet, but the other drive works OK. That Serverfault reference focused on Centos, and some of the differences in the Ubuntu family may matter, but the basic idea looks solid.

I see only the two most recent logfiles stored, so I have missed my chance this time, but I have a good idea of what to search for now. I have only seen logged a check for the sound cache folder, followed by some sort of check on the files in the texture cache. There's a lot about the CPU which comes before this. This is the first mention of the SSD partition I use. The preceding run was almost the same: no WARNING line, and all the preceding lines have the same timestamp. I don't keep the sound cache between runs (a default option in preferences), and I think that could be put in a completely different partition/location. 2022-07-07T12:30:44Z INFO #InitInfo# newview/llappviewer.cpp(1147) init : Hardware test initialization done. 2022-07-07T12:30:44Z INFO #AppInit#Directories# llfilesystem/lldir.cpp(1189) setSoundCacheDir : Setting sound cache directory: /media/dave/120GB-SSD/Dave/Firestorm_Cache 2022-07-07T12:30:45Z INFO # llfilesystem/lldiskcache.cpp(150) purge : Purging cache to a maximum of 10468982784 bytes 2022-07-07T12:30:45Z INFO #TextureCache# newview/lltexturecache.cpp(1062) initCache : Headers: 1048576 Textures size: 8344 MB 2022-07-07T12:30:45Z INFO #THREAD# llcommon/llthread.cpp(145) threadRun : Started thread PurgeDiskCacheThread 2022-07-07T12:30:45Z INFO # newview/lltexturecache.cpp(1801) purgeTextures : TEXTURE CACHE: Purging. 2022-07-07T12:30:45Z WARNING #TextureCache# newview/lltexturecache.cpp(1868) purgeTextures : TEXTURE CACHE BODY HAS BAD SIZE: 392334 != 5544/media/dave/120GB-SSD/Dave/Firestorm_Cache/texturecache/7/7c78f30b-2c3f-31df-b2a6-bcf7d92c79e6.texture 2022-07-07T12:30:45Z INFO #TextureCache# newview/lltexturecache.cpp(1895) purgeTextures : TEXTURE CACHE: PURGED: 1 ENTRIES: 42476 CACHE SIZE: 2485 MB 2022-07-07T12:30:45Z INFO #InitInfo# newview/llappviewer.cpp(1165) init : Cache initialization is done.

Every so often, for no apparent reason, my cache location shifts from my SSD to the conventional HDD which my viewer is installed on, Since I am running Linux I don't expect any good answers here, but I have noticed, a couple of other times, odd behaviour which could be related to assumptions about how Windows does things, buried in the program code. One instance of this is the Linux version of Firestorm ignoring my OS-level settings for Cursor size. Since my programming limit is shell scripts ("batch files" for Windows users) the suggestion that I submit a patch is rather useless. Once or twice, it's possible that the switch of location is connected to a more-complicated-than-usual system restart, but I rarely start my viewer immediately after a system restart. Anyway, I am assuming that, buried in the viewer code, is a check that the cache location is working, and an automatic reversion to the default location if the check fails. This is, on my machine. on the same drive partition that Firestorm is loading and running from. I admit I would rather have the program loading stop, with an error message, than a change like this which forces a large cache to be cleared. What might be tolerable with the default cache size is questionable with the cache set to the maximum size. A lot of new textures, not currently cached, slows the frame rate. That may be a consequence of the limited multi-threading capacity of viewers: I know Firestorm shows no sign of generating a significant multi-core load on my computer. I can think of several people who might be able to shed some light on this. And several whose replies will evoke Shakespeare—It is a tale told by an idiot, full of sound and fury, signifying nothing—I got a lot of Shakespeare at school, but the teachers fitted that quote rather too well.

There's also Murphy's law of PSU failure. It always lets the smoke out on a holiday weekend. Failure may seem easy to fix, and a PSU has plugs and sockets for connections, but there's still a fair bit of your time spent on taking out the old and putting in the new. How long do you spend on getting a replacement? But if you have a margin, a PSU can last a long time.

I know some details have confused me, and the 515.xx series are the Linux drivers while the 516.xx series are for Windows. Since a PC can run Linux or Windows, it's even able to give you a choice at boot time if you want to set it up that way, just saying "PC" could lead to confusion. I am now running 515.57, which is the latest Linux version, and it has the bugfix. I would still recommend waiting for it to come through your distribution's normal upgrade channel. The NVIDIA version is generic, and there are options you have to choose, and it feels a bit scary.

I am muttering somewhat about they way some reporting of this issue managed to lose that v516.40 was a Windows driver while the Linus/Unix equivalent was v515.48 But no, what we got was "Update: the issues described blow have also been noted on Nvidia drivers 512.95 and 515.48." And so context is lost for anyone who doesn't keep track of the version numbers. I just upgraded when a new version of my distribution's recommended driver came out.

NVIDIA have now brought out v516.59 for Windows, which is reported to correct the problem. I am not sure that a fix is out for Linux yet.

Inara Pey has reported that there are a couple of other dodgy version numbers, NVIDIA driver versions 512.95 and 515.48 My distribution does make v515.48.07 available, but nothing later. I was using the 470 series, which still gets regular updates, but is old enough that I switched to v510.73.05 — I think I should have done that a while back, but it was still working. I know I have good video hardware, and there has been a lot of fake hardware infesting the markets. I am not in any hurry to change.

I had a look on the NVIDIA site, and the Studio drivers are apparently not available for Linux But my video card is a bit old and that may be affecting what choices NVIDIA are offering me. If you are using Linux, you may have more options from going through your distribution's native upgrade system.

There are aspects of the Bellisaria lines which fit uneasily with the old SLRR scripts, and I can't see anything different you could have done. My railway knowledge and experience is mostly British, that RL source for a lot of the visible signalling hardware. It's hard to scale from RL to SL, but some of the double-track sections around Newbrooke feel unduly long. They're not mere passing loops. If we saw authentic train operation, with block sections and electric token working, I expect the screaming would never stop.

I've been mostly out of touch with things, only now realised that the Chalet line is now part of a pretty big loop that runs around Newbrooke. And the Infinity brand avoids so many of the hassles that arise from the ancient SLRR scripts..