SL LUG 7th June : Meeting Karen Linden

The next meeting of the SL LUG will take place on Wednesday 7th June, 12pm SLT (8pm BST, 9pm CET) at Maryport (182,150) (Find -> Events -> check upcoming -> search for 'Linux').

I will update this post with details of the second later SL LUG meeting once I have spoken to Drake Bacon (turn on IM in you forum profile!)

Meeting Karen Linden
Karen Linden (Dev. Program Manager) will be coming to the 12:00 Meeting to have a chat about the current state and future of the Linux client (W0000T!) Thanks to Zi Ree for organising

We are wanting to put a short list of questions together and get them over to Karen in advance of the meeting. So, if you have a question please post it in this thread, the LUG officers (Currently myself and Zi Ree) will go through and pick a handfull of the best ones. If you want to stand a good chance of your question being picked, please make it a good one

Just a reminder, the LUG is a friendly meeting place and the grounds are open to everybody and anybody at anytime - So if you want to get together and chat inworld (and save the group chat) please feel free to use the LUG.

Okay, here are some question ideas to toss around:

- General information politics: How can we improve communication?
- Can we get the Linux Client into the Release Notes? Even if there was no bug fixing done?
- Who is working on the Linux Client now?
- Can we get their Mail address / can we IM them? Get a regular status update?
- How much work is put into the Linux client (hours/week)?
- Anything we can do besides submitting bug reports?
- What about the line break bug? Sounds like a one-minute fix. Please do it!
- Would Karen agree to spend one day as a Linux Client user, with all community support we can give?
- If we would agree to sign an NDA and don't charge money, would LL let one/some of us work on the client/fix bugs on a volunteer basis? If not, why not?
- Will one of the Linux Client users be invited to Second Life Views?

More questions will be added as an edit if more come to mind.

How about a change log for each version? I know that some changes are listed, though behind the scenes fixes are often not disclosed.

My question would be:

"Beyond fixing the obvious crashing issue with the native client, would it be possible to fix the avatar handling between the Linux and Windows versions"

(I'm starting to get a complex about having a permanent brown head and beard )

Addition to the ideas,
- Have a linux client on preview.

This ofcourse only makes sence if they actually change the client.

-- Linux manager as part of LL? Someone to keep everything to do with the linux client up to date and under control.

Is LL open to being sent a remastered "LiveCD" of, say, Ubuntu/Kubuntu or Knoppix that allows testing of the Linux client w/o dedicating PC to Linux?

Does LL need help installing Linux?

Heh .. good stuff.

Sounds like a really nice idea! If a few of the more talented of the Linux crowd were allowed to get involved (Major Senior? Kick Madonna? Darkside Eldrich? Probably quite a few more...) I am sure things would get sorted pretty quickly.. Be really interesting to get her response!

This is a Wine problem. Not a SL specific problem AFAIK. It does not affect the native linux client (any more!)

Can I just point out (as I got caught out by this yesterday) that the time in the UK is actually 8PM BST, not GMT, as we're on daylight savings time here.

I suppose if I'd been on SL longer I would be living on SLT, but I'm not there quite yet !

They do, see the change in version numbers

I would also like to see it on preview, so the Sudden Deaths we are experiencing can go to the Preview Coders for their urgent attention, while they are still deep in the modifications they have made.

This would be one of the more useful possibilities in stabalizing the Linux client so long as someone on the dev side was going to chase the bug reports. At the same time, I suspect this would give the impression that the Linux client is "officially" supported. Not certain if that is the view the Linden's currently want to give.

Misunderstanding of terminologies here? I am assuming this behavior is a result of the alpha problems in wine in refering to textures with alpha channels. Very much nothing to do with the alpha status of the linux alpha client.

Thats exactly it.

They Do.

Karen has said so, and before her Don, and it has been moved to the official download page.

It is in Alpha, but in the main codestream. It is not the personal hobby of a rogue programmer

Whether pople who do previews actually get to our bugs is sort of beside the point; looking at them will often give pointers to inherent stabilty problems in the client itself. Linux is notorious for using the hardware at its outer limits; if linux has NO problems, then the code is usually stable on the other platforms (I mean Apple or Windows). The reverse is not always true

Honestly, I am a bit more skeptical. I understand that some people in the dev group seem to want to make it officially supported, but it deffinately is not treated that way. My take on an alpha release is just that, alpha, unsupported, untested, use at your own risk, no garantees, don't file a bug report. The first step in making something like this a supported target would actually be to roll it to beta "as is", dump its builds onto the preview grid with everything else, and dedicated a few people to sifting through bugs, even if those people are free volunteers from the community.

There is a large group of people in the linux community here, and a lot of free resources to be had. Those of us from the community understand how this sort of dev works .. the labs might not quite understand that aspect as well as we do. It is really easy to ask for a few volunteers to sift through and keep a list of known bugs, with relivant logs, kick out duplicates, ect, and act as a liason to the labs for known issues.

Further more, we have some really powerful tools at our disposal. Tweaking the secondlife startup script to start up the binary with gdb enabled and setting up a simple .gdb-sl in the SL directory for stop-hook'ing backtraces and automating a ton of this stuff for them is braindead simple. This isn't like its work or effort, it is a matter of how much information do they want, and how would they like it to flow to them without overwelming them. Open Source produces some amazing code .. and much of that is thanks to our tools. Something we aren't using much of in regards to the SL situation, perhaps on part because there is a bit of uncertainty when you are sitting down disassembling binaries into assembly code to figure out a problem ... you don't know if you are violating the terms of service.

But my first expectation, above and beyond someones words about what they would like, are some minor actions. What the linden's do in the end is their call. Their code, their work. As a programmer, I respect another programmers decisions about what they do with their source, so in that regards, I wont complain. In the end I am just outlining a scenerio that makes a bit more sense to me for the resorces available. Right now the biggest problem with the linux client stems from the lack of information flow. We aren't getting much back, and contrary to some views .. we aren't actually sending that much up the line. Not in comparison to what we can and likely should be sending.

Not quite, though the rest of your post is apt, and has been said 1000 times on this forum.

We have been asked to post bug reports, and bug reports was one of the first fixes to the client.

It seems to be a resource and priority issue. It is also true that the existence of the Alpha Linux Client is not well known, outside of the Lindens directly involved.

However, Linux and Alpha are both geeky things and I bet ALL the geeky Lindens know about it, and are pushing for it. Take a look at the officers in the Linux Client Users group. For a LONG time, only Lindens and the odd developer were officers.One of our major achievements as Linux Client Users was to get "official" by getting two residents as officers.

It will take time for the Linux Client to get a Big Push, which it needs to go Beta, but that Karen Linden is coming to an in-world meeting of Linux Users is really a HUGE achievement.

So I wouldn't hold my breath, but I am carrying on working at it, in my own little way

Correct.

But to confuse things slightly more, the linux client used to show exactly the same alpha display problem as seen with running the windows client under wine until a community fix was submitted for the linux client (I confess I forget who came up with it - sorry!).

Correct.

But to confuse things slightly more, the linux client used to show exactly the same problem as seen with running the windows client under wine until a community fix was submitted for the linux client (I confess I forget who came up with it - sorry!).

Aye, I am just thinking of the level of structure the community is maintaining, seperate from the linden's. And yes I recognize that there has been much work done among people, but to me the community feels sort of .. I dunno, disorganized, or loosely knit. *shrug* There are tons of things that can be done to debug a variety of things, as well as things that can be done to reduce a variety of problems on the linux side w/out needing access to the code.

1) pasting into the client - there is already a discussion on this outlining a variety of ways to get this done as an interim solution until the SL client supports the X11 cut/paste events.

2) Streaming sound from a region. - streamed audio is just a url for an area .. anyone have any idea if we can scrub logs or look at any data on the client side to locate the streamed audio url and trigger our own players to point at this url? while it is possible to hijack the data off the network connection between the client and the server .. this gets into the realm of poking the terms of service, would prefer a way that is less questionable.

3) better debugging - settup some gdb scripts customized for the SL community and a replacement secondlife startup script to fire up second life for people under gdb and automate some of the debugging. Would like some clarification on if we are going to get .. in trouble .. for disassembling the binaries at crash points. I know it seems a bit of a silly question, but the terms of service make that a bit odd. Would just like some words of comfort there more then anything.

4) Start a sticky thread for known issues on a per-version basis instead of trying to track them all in the same thread. The current known issues thread is a bit .. loaded.

And yes, I am likely rehashing things that have been brought up before.. there is just so much data in the forums at this point. Would be nice to figure out some way to organize that. Would almost prefer a wiki over the forums, or better yet a Trac.

Kick Madonna almost got this working, so he would be a good person to quiz about this.

Just to drag everyone back on topic - Questions for Karen please

Honestly, I think my questions are already stated in what I said. I am less interested in knowing who exacly is working on this stuff as I am in finding out what how much information they want back, and how they would like to recieve it.

That name is no longer a valid SL name, on or offline.