Linux Client a Priority?

It does, except that there are numerous bugs in most of the display library sets required for doing accelerated 3D to the various X servers.


Unfortunately, this isn't true these days. Linux is a buzzword of the computer world, and while I agree to properly use a Linux workstation you need to know more than the average bear, this is why it's a problem. A lot of people using it now simply do not.


Mmmhmm, and which X server do they support? Xorg, XF86, etc? What drawing library will they support? How will they handle full-screen OpenGL and window management thereof? Motif? GTK? What standard library should they be built against? glibc? which version of it? What package format should it be distributed in? tar/gz? RPM? deb? Should they rely upon VM optimizations in the 2.6 kernel? Or do they need to remain backwards compatible with the 2.2 and sacrifice performance?

That's the problem with supporting 'Linux'. It's about as difficult as supporting "Windows". They've cut Windows down to 2000/XP. Would you all still be happy if they only supported a Linux client for RedHat and SuSE? If they run into a vendor related issue, who do they rely upon for support otherwise?

This is actually part of what I do for a living. I'm a UNIX/Linux Systems Engineer, and currently a large portion of my job is helping large Solaris environments migrate to blade-server Linux environments. It's a mess, because there are a lot of holes when it comes to trying to be a business and rely or support Linux. For the casual user these aren't really a concern, but when you agree to "support" it, it becomes a big problem. At this point in time there is a severe lack of standardization in the Linux community, and when it comes to production level support that becomes an issue.

I don't know if any of this is really a problem for LL, they're extremely good and handling business development on fairly bleeding edge technology methods so far. They may have ways to handle this whole mess and be beyond it. These are just the problems that I see for them if they move ahead with actual support of Linux clients.

Standardization of non-homogenous clients in supportable manners is not easy. I think it can be done, but from my view of LL I think it would be damaging to their progress with SL.

You target X.org since that's what everyone is using -- the only major Linux distro that still supports XFree86 is Conectiva. Not that it should matter, as the X11R6 protocol is standard. Since SecondLife does its own widgets, you don't need to worry about what desktop manager/widget set is installed. If you only link against libraries using the C ABI, you don't need to worry about what compiler was used. Link against libGL, and let the driver installation sort out whether that's Mesa, NVidia, or ATI -- and if it turns out it's Mesa, laugh when they file the bug report about the framerate being measured in frames per minute. Multithreading could be a problem, as the only standard is the heavyweight multiprocessing using fork(). Other than that, link against libc, libm, and don't worry about the kernel version -- it doesn't make much difference.

Actually, pthreads is quite standard. It does stand for POSIX threads, after all..

I feel pretty much the same way. There's a very specific distro of linux I'm salivating to move to that will support all the apps I use in my work with full compatibility.. the only thing is SL holding me back.

Though linux isn't the best OS out there (yeah yeah), I'm just sick of Windows' memory mismanagement and can't afford an over-priced mac. So a decent distro of linux will have to do.

I really hope they do release a linux client soon.

Carnildo's pretty much 100% correct on this one, and si Money, I don't recognize even a fraction of the problems you're talking about, and I work with Linux systems of many different types. Maybe a few years ago, things were quite a bit messier in those days, but not now. Most x86 Linux binaries are pretty compatible right across many distros, and game binaries even more so because they tend to be self-contained.

Not sure why you're spreading FUD on this. I'm sure it's not intended, but you're simply quite a way off base. Portability across distros is quite easy to achieve.

If you don't want a native Linux client, fine. But hammering against those who desire it quite desperately is not very cool.

Yah well I had a nice little note all written up to explain this all to everyone. Of course, much to my suprise, it didn't take.

Here is the bottom line if you don't get it, I know a lot of over priced crap software with your name on it.

Linux is here to stay it is. In to many ways to count superior to windows powered down. Linux/Unix users don't even know wtf defrag means, and never have to reboot (almost), certainly not 6 ($#@$@%) times just because they installed some software.

You get to use all your ram (3gig switch my azz), IO actually functions and wtf is a rescue disk.

Longhorn is a 2 year late 6 part joke (do you even know what longhorn is? then wtf are you talking to me for).

Most game developers with half a brain either have or are working on linux versions of there game if not building in linux.

There is really nothing to talk about here. The only reason anyone who knows anything about computers here is using windows is to play games period.

XP rocks??? obviously that is some strange usage of the expression I wasn't previously aware of.

Welcome to the world of open source ladies and gentlemen, get used to it.

Try to run a binary from a Debian stable system on a Redhat WS 4.0 system.

Hell, try to run a binary from a Redhat WS4.0 system on a Redhat WS3.0 system.

There are some compatibility "chains", IE: RedHat 7.3 -> RedHat WS 2.1 (i think?) -> SuSE 8 -> Mandrake somethin that do work, but going across 'major' releases very rarely works

The core system libraries really aren't compatible across systems. A lot of times you can work around it by simply symlinking a library of a newer version back to it's older sibling, but they do update those version numbers for a reason.

If you're just running your own systems, it's not a problem. However, I run several thousand systems of various version levels for hundreds of separate environments, not to mention my own IT systems. Trust me, you find a LOT of binary incompatibility when it's not your own system that you can control what is/isn't installed, and what errata is applied.

I'm not thinking from the perspective of a user managing their own system and trying to maintain proper binary compatibility, or even a user who has a binary which is missing a compatible library to make it possible. I'm thinking from the terms of Lindenlab support, who will have (For the sake of argument, i'll side with you guys) thousands of varied Linux users.

If you assume 60% of them have no clue how dynamic linking works (and that's a low estimate, I can assure you), and assume that 25% of those users have their systems running libararies which are for some reason incompatible with what is needed for the SL client (perhaps systems such as Linspire), think of some math

5000 * .6 = 3000 * .25 = 750 people who will have gameplay issues that LL has to come up with resolution to. Even with 4250 doing just fine, it's still a big headache.

There are technical solutions to this, of course. However, to say you can't see the possibility of the problem seems like you're trying to ignore it.

I'm not saying these problems are any different than any other OS -- they aren't. They all existed in Windows (just look at the grief it causes).

Personally -- i'd love a Linux client. It would be that much closer to it being available in an OS of my choice, and in fact, I could probably even get it going on IRIX or HP-UX with binary compatibility. However, I personally still feel it would not be a good idea for Lindenlab.

Here's an extract taken from the log of Cory Linden's Town Hall chat, held earlier today --- the part referring to work on the native Linux client:

And this is why the option for linking libraries statically exists.. or if because of licensing you provide the binary/source of the library separately (ie not compiled into your program), you can put it in the dir-tree of the program..

Yes this adds space to the binary, unlike using the existing libraries, but compared to SL's cache it is not worth worrying about.

I agree totally. And anyway, the size of a binary is a meaningless issue for a long-lived program like the SL viewer.

That said, if they wished to reduce the size of the download for update purposes, they could place entirely statically linked Linux interface code into its own .so file, and then dynamically load this unchanging interface module from the main regularly-updated viewer code.

There are many ways to swing a cat.

AGREE!
Maybe Linden Labs saved themselves SOME dollars, but it had cost me around $100 to buy a WinXP Home Edition, for SL!

I would've rather saved that $100, though yes, probably other games would need XP sooner or later, too, but still...

The only reason I have one of my pc's running Windows XP pro is because Second Life either isnt on the ball with a linux client or Windows and Mac takes precedence over Linux. I dont know how long we have to discuss that we need a linux version of the game before they will get to it. More then likely if your guess is as good as mine...hmmm ... let me see..could it take as long as it takes them to patch the game like they do now or fix login problems with servers they run now. DARNIT SL peeps just give me the source as I will write a Linux version.

Linden Labs SUPPOSEDLY has an outside contractor doing the porting, they promise it around 1.7-1.8 (2-6 months).

Yes, they've kept promising and promising and promising... but maybe it's for real this time (i hope so

After reading through 6+ pages of posts here I have come to one conclusion:

Open source the client code.

Linden Labs is very busy working on the Windows and MAC code. There seem to be a small army of people here that would work on a Linux port of the code. I realize that the client code probably has trade secrets in it. People want to be in SL. They will pay to use the SL world servers. The client is just that. A client. There has to be a way to allow outsiders to work on the code.

I don't know if the Lindens read this, but if you do can you please consider opening up the client code for Linux so that the enthusiast community that has grown up around your platform can take a crack at getting what they want: a working Linux client.

Well as a point and click booger eating moron, I could careless if they put a linux client out. Windows works, its compatible, and i don't have to know anything about how it works to use it. I have job, even a technical job, and I like windows because it means I can just work, or play without worrying about it. I'd rather shop for shoes than learn linux.

However, I concede, that linux is a viable alterantive OS, and that really LL should have linux client as well. The tekki-wikkis that do use linux are indeed very creative and it would be nce to have a better participation from that community. It should be a priority.

Perhaps the MAC developers can be freed up now to work on the Linux client. Come on Linden Labs, your gonna have to do it sooner or later!

http://news.com.com/Apple+to+ditch+IBM%2C+switch+to+Intel+chips/2100-1006_3-5731398.html?tag=nefd.lede

Even as a Windows user, I would really support a Linux client.

Linux users are very Code-Inclined and generally gifted with the ability to script exceptionally well. As a Consumer Whore, I would like to see higher quality scripts being placed into the objects that I so frequently blow wads of cash over.

Seriosly through, The release of the Mac Client did see an upscale of Artfully inclined folks, I'd like to see the effects of a Linux Version.

Could use part of VLC and integrate it it into the Secondlife client to get quicktime streaming first of all.

And even so, why would movie streaming stop them from making a linux version of a secondlife client, so quicktime movie streaming isn't supported yet on linux.



Have you even tried to buy Cedega? I can't find a simple buy button for it, nope, not a single way, only stupid support which I don't want. I don't want to buy needless support for it, I just want the product. Not to mention it's a horrible pain to have to go and buy another commercial product to play a game.

Cedega is sold on a subscription basis, its $5/month for all the updates (but you dont have to keep paying, just buy the minimum 3 month subscription for $15 and there you go.), but it wont do you a whole heap of help with SL, since it's still fairly broken. You want WineX3.2 which can be obtained via Transgaming CVS free (or you can use a transgaming subscription to get Point2Play which simplifies things a lot).

VLC in my opinion is rubbish. Running through libav would be the better route since it means whatever libav supports SL will support (even through upgrades to libav), LIBAV is based on the mplayer decoder (which is what VLC is based on as well), so it handles a lot of filetypes (moreso after the fork), but unfortunately, the newer releases of quicktime is not among them since Apple insists on changing the format consistently. (although last I heard there was good progress on the front of getting H264 support)

-Adam

Has anyone tried win4lin? I've tried cvswinex, wine, Crossover Office, Vmware. Now I'm dual booting. The only one I got to work is Crossover office and it crashes when the character loads. It refreshes horribly too.

It would have a major effect on me. When I work at home I'm on the linux side of my dual-boot notebook. I don't want to muck around in a non-native emulator - I want a real X client from LL.

I don't mind if there is no quicktime or streaming movie support in Linux SL. Just please let me use SL from Linux.

I went to a really nice formal ball last night and it reminded me how much fun just living in SL can be, and taking part in stuff.

It's awful but I'm constantly unable to take part in SL because I like Linux and that's where I am and that's my OS

I've threatened to leave SL but I'll be honest, I probably never will cause I like it too much. It's a shame that as long as there is no linux client I'll be running at about 10% or less in SL. I could be scripting, I could have a window to SL open in another workspace, I could be working on my home...

Maybe I don't matter that much, but after all this time waiting for the ages delayed SL Linux client I'm feeling a bit saddened and downtrodden.

Why should LL invest all this money in building a client for an OS with single digit desktop market share? Couldnt't that money and efforts be spent on something that would affect a larger segment of the population. It is bad enough they waste efforts on Apple with it's 2% market share that is sure to decline with their lastest idiotic monopoly moves.

Well alright then, it's windows or the highway. I'm sad I won't be able to contribute to SL anymore. Or anyone else who doesn't like to use Windows.

We wish to announce the following misprint. It was publicised the Linux client would ship in Q1 2005. This was a mistake. The announcement should have read Q1 2015. We apologise for any inconvenience this may cause.