What do we want before SL Linux goes Beta?

Now that SL Linux is REALLY Wow So Much Better, I want the world

Suggestions:

Cut & Paste

Ripple Water

All Graphics Options enabled - if it crashes on one, we report it

Critical Libraries in the tarball

Separate Tarball for i686 and 64 bit, including critical libraries, or alternatively, shipping with both sets of libraries

Anything else that is critical?

We are on a roll!

More controlled logging would be nice. Though not a stability issue it just makes things cleaner. Perhaps a SL.log that logs just the client instead of putting it in the system/user/message logs.

As a catgirl, I really would like:
SHINY
SHINY
SHINY
SHINY

Also, cut'n paste and file save/upload dialogs

Those are like my must haves at the moment.

Seconded.

All the other things have already been said, so I just add my list:

ALSA sound support and the ability to select the output device either in the client or settings.xml would be great.

Keyboard repeat does not work yet.

Keep up the good work! Tofu, you are a life saver

AGP detection..

This is mainly an annoyance, but often I find the "less" button on the build dialog doesn't remove the lower portion properly - it leaves a transparent (inactive) version of it behind.

I'm not sure I explained that terribly well, sorry.

Not critical, but desirable: Make it behave like a proper Linux application. Move the config files and cache to $HOME/.secondlife, so that upgrades would be easier to do, and one copy could be used by multiple users.

Perhaps add autoupdate as well. Make files in ~/.secondlife override the system's installation.

Updating! i noticed it doesnt auto update when the update button is clicked <for Ubuntu that is>

Thanks very much for the feedback! A few of the requested things above are fixed internally here and will almost certainly be in the next release (the 'official' update planned for Wednesday). Most of the rest of these requests are very firmly on the TODO list.

We really do appreciate all of your suggestions and bug reports! I'm as happy as anyone to see more progress on the Linux client lately.

Tofu, you are the GREATEST!

We have had more progress in the last two weeks that the entire Alpha Period before!

If you make it to an LUG meeting, you are entitled to a free glass of champagne - I kept you one

weeee

I noticed I don't have ambient sounds yet... Is it just me?

I (usually) get streaming music, though...

If it's everyone, it would be another "I would LOVE to have" before Beta.

-- edit --- It's just me - sound turned down too low --- end edit ---


As for the packaging:

I like the /opt/Secondlife pattern, with personal settings in .secondlife of the user, Av settings in a folder with the name of the Av under .secondlife. Cache directories also under .secondlife. That keeps Secondife libs etc out of the system libs, and the areas where the linux user has to write, in his own home directory space.

I don't understand what AGP detection *does*. Texture handling in OpenGL is very much abstracted, to the point that it actually makes it impossible to intelligently handle texture swapping in your program. The Unreal engine people were complaining about this years ago. (So maybe there's some new extentions for this since then, I haven't done OpenGL in years...)

How is it now detecting the VRAM size, anyway? Whats the secret?

Since copy and paste is apparently fixed already, we need uploading!

Also the logging thing is annoying. The system log is ment for system level daemons, not user programs. I guess its arguable as to if users should even be able to use it in the first place. This is why I like open source, if I had the source to SL, I could just comment out the call to syslog() myself. Its a trivial one line fix. ;P

And one thing that annoys me, ogg streaming crashes the client! And its not just Linux, it has been crashing OSX users too for a while now.

Coming from the Fedora project, we won't ship MP3 support because its patent encumbered. ...But never mind that, vorbis is simply vastly superior audio quality at all bitrates. The difference is like night and day.

Okay I see in another thread, the logging thing is fixed already. Go Tofu!

Hi all!

I have found that when I start SL Linux again in windowed mode, the positioning of my IM and chat history windows, and the mini map, does not get preserved from my last run. This would be nice to have working again - it worked before, so I would think it is not THAT much of an exotic fix

It may be related to the "windows only setable to 800 x 600 in the GUI" problem we already have.

I have also experienced Drake Bacon's problem of SL not shutting down cleanly. Killing the terminal window where I started SL works. However, this only happens now and again, not always.

A NEW phenomenon, which I am not happy with is that SL Linux now runs with load levels of 1.8 and higher as shown in Xosview, instead of a constant 1 as in the old version - this MAY be the addition of sound, which we may have to live with. Vmstat also show 2 processes constantly running - the "r" column. On the OTHER hand, that means that the Dual Core People WILL have a performance boost compared to us single core peasants

I would really love Cut & Paste, and File Upload. I find that without these, content creation is too much of a struggle. Personally, I am willing to put up with a bit of quirkies and experiancial lacks, when it just does not happen, it is very frustrating. Though I guess stability or at least controlled failure (eg auto-save anything you are working on/auto-save to special folder etc on crash would be nice.)

On the subject of ~/.secondlife, this is actually something I have been meaning to bring up: the cache is potentially big. Often I size my application and home directory disks somewhat small in comparison, and then have large "data", or temporary spaces (this separation gives "this is stuff I need to backup" and "this is stuff I could lose". So it would actually be nice to NOT put the cache in the home directory on Linux or Windows. I would really love to see a config variable to say exactly where to put the cache so I could put it on a large disk on Windows, or in /var/tmp on Linux. I just stuck all of SL on my "could lose" disk, since most of my state is up on the server, so sticking the cache in my home directory would be a pain. However, under Linux at least I could make a softlink, whereas in Windows they don't seem to have links that work that way, so....

Thank you again Tofu and the rest of the Linux people.

Just remembered: Use a good file open dialog (the KDE one please!) and make it remember the last location used. Having to navigate to the right path every time is a pain.

Perhaps you could make everybody happy by making the dialog external to the application. For KDE, it's very simple: Call "kdialog -getopenfilename $PATH $FILTER". It opens a dialog and then outputs the selected files on stdout. Just let the user choose between that and a Gnome version, for instance by letting the user make a symlink to the version they like. Googling seems to indicate the Gnome version of this is called "zenity".

And what exactly is wrong with that? All it shows that now there are two processes instead of one. 1 process that wants to do more than there is CPU power for will keep the load averate at 1. Split it in two, and how you get 1.8 because part of the code still runs 100% of the time, and the other part 80%. But really you're still getting the same effective load.

It's not really showing any change that could be considered meaningful. One process switching internally between 10 tasks, getting a loadavg of 1, and the same program split into 10 processes with a loadavg of 10 will be getting pretty much the same performance, excluding minor differences due to context switches and IPC.

Load 1.8 means the system would fully load 1.8 cpu's and I only have one ... so that means loss in FPS compared to the same system running at load 1. At least, that is how we evaluated load on our Solaris Database machines

Since SL Linux is not doing any more than before, it means that it is getting less cycles for FPS than before.

As I said, I presume it is the sound stuff... But my FPS is not THAT bad

However, despite being convinced I know everything, I am open to correction since I am aware that my "everything" is extremely narrow in scope

I don't understand why people obsess over load average. Its very misleading if you don't understand whats going on. I find it to be mostly meaningless.

Its an average count of how many processes are on the run queue over time. It has next to nothing to do with the actual CPU time taken. A hundred processes using 0.05% CPU time could put your load average at 100, even though they're only using 5% CPU time total.

One thing many don't seem to know is processes waiting on IO are counted in the load average, even though they are not actually executing. An audio thread waiting for the sound card for example. They're still on the run queue. If you have 100 processes waiting on IO, your load average will be at 100, even though they are using no CPU time.

I had a friend years back who just couldn't wrap his brain around how the Half Life dedicated server kept his load average at 10 even though it was taking only 30% CPU time.

Not really. That assumption is only valid when you don't split the original task. Example:

Take something like distributed.net. Run one copy. Your load average is 1.

Now run 2 copies. Your load average is now 2, as there are two processes wanting the CPU, but roughly half the work gets done on each process -- total output: The about same on one CPU. If you had two, you'd be getting twice the output.

So, on one CPU, doing the task in 1 process or in 2 doesn't really make much difference. For a single CPU machine the only result is incurring in overhead like context switches and IPC, but any Linux box already has about a hundred processes running, one more won't make a noticeable difference.




The problem here is that you're confusing two different situations: Concurrent tasks, and split tasks. I'm assuming here that SL isn't doing more work than before, it just uses two processes for it.

Taking one task and turning it into two processes doubles the load average, but doesn't really change the work done. Try a test. Read say, 50 MB from /dev/urandom, then compress it. If you do this one after another, load would be 1, taking say, 30 seconds. If you do them in parallel using a pipe, load will be 2, still using 30 seconds on one CPU but less if you have more than one.

Now, different concurrent tasks are a different thing. I don't know about Oracle, but Postgresql uses one process per connection. So one big query running can take 100% of one CPU, and a second query running at the same time can use another. But this is a completely different case because running two different tasks at once isn't the same as splitting a task in two.

Actually, all this seems to explain very nicely why the Linux native gets almost twice the FPS of the Wine version on my dual Athlon

File uploads and downloads are my absolute number one top priority! Currently, no "select file path" dialog appears, and I know of no way to manually specify a path. (Other than that, uploading seems to work fine, e.g. I can upload snapshots without any trouble.) This affects:

1. Upload Image
   
2. Upload Animation
   
3. Upload Sound
   
4. Bulk Upload
   
5. Save Texture as...
   
6. Snapshot to Disk [in File menu]
   
7. Save snapshot to hard drive [in the snapshot window]
   
8. Start/Stop Movie to Disk
   

Without these abilities, I am crippled as a designer, animator, texture painter, photographer, and machinematographer.

I would also mention the lack of Copy & Paste (which cripples me as a scripter and resident in general), but it has already been added in the preview client!

Many thanks to Dale and Seg!

I am of course very superficial in my knowledge of what Load means, I see

And the explanations you both gave are very useful. I am a pragmatist, and make absolutely no effort to find out more than I need to to resolve my current issue - and frankly, SL Linux loading my system to 1.8 is not an issue - FPS down would be

Now that I know everything about Linux in a slightly wider scope , I will relax and enjoy the innate superiority that comes from using a full-blooded operating system.

I still have the sneaking feeling that SL Linux is not multi-threaded, but that the sound server is being loaded as well - and hence the 1.8 load. But as was very well pointed out, this does not necessarily mean my SL Linux will be slower - it does mean that the multi core people will get to use both cores effectively!

SL client does have four visible threads, but sadly doesn't use fork() which allows the use of multiple cores. So, those with dual core or multiprocessor of any type end up with one core at 100% and the other running the rest of the system if the system attempts to load balance. Maybe sometime there will be forking!