Tips for the SL Linux Client

Direct Rendering works just fine. I think I already mentioned that Doom 3 plays nicely glxgears gives me around 1500fps

Only bit of interest I could find in the startup log is:

2006-02-08T01:29:23Z WARNING: Frame buffer has less than 8 bits of alpha.  Avatar texture compositing will fail.
2006-02-08T01:29:23Z INFO: Couldn't initialize mipmap generation
2006-02-08T01:29:23Z INFO: Couldn't initialize GL_EXT_paletted_texture
2006-02-08T01:29:23Z INFO: Couldn't initialize GL_NV_vertex_array_range
2006-02-08T01:29:23Z INFO: Couldn't initialize GL_NV_fence
2006-02-08T01:29:23Z INFO: Couldn't initialize separate specular color
2006-02-08T01:29:23Z INFO: Couldn't initialize anisotropic filtering
2006-02-08T01:29:23Z WARNING: Unknown feature mask NVIDIA
2006-02-08T01:29:23Z INFO: Graphics Card memory set to 256 MB

There's also some errors about not finding some ATI-specific OpenGL extensions which when combined with the info about Linden demoing this client on an ATI card makes me wonder if the code is more optimised for those than nVidia.

I have the exact same output with the Linux alpha, with an nVidia GeForce 6100 on-board GPU using Debian sid with the Debian-packaged X.org 6.9.0.dfsg.1-4 on a 2.6.15.1-based kernel from Debian sources. (The CPU is an Athlon 64 3000+ running in 32-bit mode.) I had the mangled appearance problem described in this thread when using WINE, and I'm still having it with the Linux alpha. This log output is almost certainly the crux of the matter, and hopefully a Linden will take a look at it soon.

Thanks for the tip, but trust me, I've already tried that... tried all the different sound drivers at my disposal (oss, alsa, arts) too, but they all act about the same.

I do notice that the stuttering seems to be not as frequent when there's less to render... for example when I'm on my beachfront home property looking out over the ocean. This leads me to believe that it may be the audio thread (is there a separate audio thread?) being starved for cycles because Wine doesn't give it a high enough priority.

Also an issue in my setup is alsa dmix... I have pretty crap audio hardware (onboard CM873 which I don't think has a hw mixer, *and* I use SPDIF out to my receiver, which only accepts certain samplerates, so everything has to get mixed and possibly rateconverted in software, and is competing for cycles on my poor Athlon 1700+. Of course, sound worked just fine using WineX pre-SL 1.7, so obviously the hardware *is* sufficient, just the software needs to be adjusted to handle it.

It'll be interesting to see how the native client sound works once that's implemented. Code, Icculus, code!

~Orenj~

After months and months and months of eliminating issues from people's Dropline installs when the best that can be said about the version of Slackware they've installed on would be "once was 10 point something" or "Vector Linux" I can handle sorting out ABI issues, thanks.

Actually, one of my goals was to force the client to crash in new and interesting ways (found at least three!), because rather often you'll see "ricers" who'll go and replace versions of libraries without ever saying a *word* about having done so when it comes time to asking for assistance, and sometimes they'll lie right to your face about having done so because they don't think it's important. I'm going to start nudging Dropline users to take a peek at it if they're bored, so I definitely want to try to explore the problem-space as carefully as possible.

Ripple Water doesn't seem to work. I'm afraid to turn on local lighting, that kills my performance even under windows.

Geforce 5900

This thread has the answer

/263/16/87995/1.html

I have that with shiny, too. Works under windows, not under linux.

I got no Shiny either. Everything else seems up to speed except that I'm a keyboarder and IT'S DRIVING ME CRAZY TO HAVE NO HOTKEYS111

Still, this is so utterly wonderful wahoo jump for joy and crash through the window...again.

Update on the packaging script thing I was working on... I'm not going to be rolling that out the way I *thought* I was for a couple of reasons. One being that at no time when I was architecting the system did I ever consider the possibility of wanting to convert a build definition into a single, monolithic script. The other being that when I did just blindly include the config settings and the functions script, the result was, well, pornographically large--and not the sort of thing you'd want to ever have to debug. While I designed the build engine itself to at a later point be able to generate things like RPM files as well as Slackware packages, it's far from being able to do that yet. Since I made a lot of use of spewdo () (pronounced "spew do" heh) in the build script anyway and that's just an ugly hack to make sure commands executed wind up in the logs, I'll probably just sit down tomorrow and import the needed functions into the thing and then publish that. People wanting to convert that to a spec file or whatever for their own uses are quite welcome to pillage anything from it they want. I'll stick the URL up here in a couple of days.

Just for general info (non-geeks/admins can skip the rest of this post) the directory schema I've been using is as follows:

~/.sl - Location of user-specific files, as outlined by Lum Kuhr (you rock dude)
/usr/share/games/SecondLife-nnnnnnnn/ - Where basically everything goes
/usr/share/games/SecondLife-nnnnnnnn/default - Skeleton of ~/.sl as outlined by Lum Kuhr
/usr/games/secondlife - Where the shell script wrapper goes

Does this setup conflict with anythiing Gentoo, Fedora, Debian or whoever (except Linspire) uses? AFACT this *mostly* complies with the FHS, although changing it to strictly complying with the FHS wouldn't really be anything intrinsically hostile to Slackware. I have every intention of making it as easy as possible for LL to do installable native packages as I can, so the info would be helpful.

/me goes back to waiting for 1.8.10

AFAICS, in Gentoo, SecondLife would be the type of thing that goes into /opt (though I'm not exactly sure what determines using /opt; binary-only stuff tends to get put there). It would be as if you just extracted the whole tarball directly into /opt (putting SL in /opt/Secondlife, dateless since it'll hopefully be able to update itself like the other platforms), with the secondlife startup script put in /usr/bin or /usr/game/bin and modified to call into the /opt directory as necessary (or a second script could be put in /usr/games/bin that calls /opt/Secondlife/secondlife, or /opt/Secondlife could be added to the PATH).

On FreeBSD it would be customary to install the execute shell script in /usr/local/bin and the Secondlife data in /usr/local/share/SecondLIfe.

Typically you don't have to worry about this though. If (and when) it gets turned into a port the port maintainer will build his own set of patches that fiddle with the directories as needed. Just try to not hardcode directory paths in the executable if possible.

Generic releases should always install into a version-tagged subdirectory of the current directory, so that personal user installs will always work regardless of the environment, and so that it doesn't stomp over earlier releases.

Specific distro installers then only need a 1-line wrapper script to adapt the release to their requirements, and don't have to worry about any funny relocation flags.

What's the point of saving old versions of the client that won't be able to connect to the grid anyway?

Only some upgrades are mandatory, and others aren't. Once the viewer becomes relatively stable, the latter type should start to predominate.

Plus, there's a ton of stuff in a release over and above the possibly-obsoleted viewer binary and libraries. It's early days in that area atm, but as the client gets more and more locally customizable (which LL have said is their plan), the less people will want their modifications overwritten.

And hell, it's simply for sanity! You don't overwrite what you have until you've checked that the replacement works .... well not if you're sensible.

I get tired of looking at blurred stuff.

If I right click (only right click) briefly on all the objects in my area, they all load fast

Hovering the mouse over an AV sharpens their detail after a while.

This tip seems to work in windows, too.

However, the textures go blurry again very fast in Linux, cache gets emptied

That's a totally "normal" use of /opt actually. With the number and type of libraries that the client is shipped with, about the only thing it needs outside of it's directory structure would be glibc.

You bring up one interesting point, tho... I don't think it's going to be possible for a user-level app to update itself like the Windows client does without eliciting some outside help from something like the consolehelper wrapper.

And that's how it should be.

Downloaded applications should have absolutely no way whatsoever of installing whatever/wherever they want --- that's a recipe for spyware and security nightmares.

Instead, the system's installation tools should always handle the process, either by getting the installation info from the package, validating it, and doing the file shifting themselves, or else by running the package's installer within a sandbox and trapping any attempt to do something that's not allowed.

Both methods are in use in different distros. Anyone who directly runs a downloaded package's own install script as root deserves all the pain that they will eventually get.

I got this tip in my inbox today, I thought it might help some people who are having issues with graphics.

I haven't tried them cos my grpahics are fine, but they look sensible.

There are separate tips for ATI and AMD64, too.

Good luck!

http://www.ubuntuforums.org/showthread.php?t=131267

The problem with search inventory can be fixed by toggling caps lock on and off a few times.

/263/cf/88689/1.html#post897610 is the original post. Thanks to Hello Toonie!

On Debian (and I'm fairly sure FHS in general), you'd want to use /usr/lib instead of /usr/share, or use both. Although I think it won't matter in this case (until there are versions of SL that are x86-incompatible), architecture-independant things should be in /usr/share, while arch-dependant things should be in /usr/lib. with the thinking being that /usr/share can be shared among many machines without worrying about architecture incompatibility.

Nah, /usr/lib would be the wrong place to put the files the Second Life client ships with because that's where libraries go that other things on the system need to use. Bumping people's versions of libz.so (for example) out of the way is a good way to get nastygrams in your inbox.

Umm... No. They've pretty much already got permissions to run anything they want on the machine by virtue of being allowed to install files to root's path. ...plus, you're not likely to be installing a package if you don't plan on using it.

There's not much utility to be had in trying to sandbox post-installation scripts. You either trust the person who made the binary package not to screw it up, or you don't (and shouldn't be installing the package in the first place). Trying to sandbox that sort of thing requires that your package manager basically know everything that any package could ever possibly need to do to finalize an installation, or your package manager simply becomes the vehicle for screwing things up.

On gentoo, game data goes to /usr/share/games/whatever, with the app itself in /usr/games/bin

FWIW, since posting how I got ~/.sl working, I've updated my script to just use a directory called secondlife rather than the specific name given by the tarball. Upgrading to 1.8.3.9 was a pain in the backside because the symlinks in my ~/.sl were still pointing to the old version.

As for apps auto updating themselves, well Azureus is a good example. Gentoo just display a message telling you to switch the auto updates off and use portage instead. I suspect this approach is true for any packaged app running on any correctly configured linux system (by which I mean any linux system where the user isn't stupid enough to do everything as root)

I'd meant using /usr/lib/games instead of /usr/share/games not just plain /usr/lib. I was just describing the differences between what's allowed in a lib dir versus what's allowed in a share dir.