Why is the SL client non-portable?

In this post on the Hotline to Linden, I approached the never-ending question of "Where is the Linux client?" from a different angle, by asking "Why is the SL client non-portable?". If it were portable in the first place then it wouldn't need porting to Linux, but merely rebuilding/recompiling, so really it is this issue that lies at the heart of this protracted affair.

Phoenix Linden wrote an absolutely excellent response to my question, not an empty PR dismissal, but a reply with sufficient detail to be satisfying on a technical level. Thank you Phoenix. Here's a sort of "porting problem sheet" summary made from Phoenix's list and with his other relevant issues added in (paraphrasing slightly for brevity, I hope that I've done it accurately and that it's OK with you, Phoenix, edit it if not):


That list is eye-opening, and very sad for those of us who have been trying to be optimistic about the prospects of a native Linux client being released. What the above list very clearly indicates is that the SL client is not even close to being inherently portable. Indeed, a list of that magnitude is a major project spec in its own right. It's very disappointing.

In my question to the Hotline, I threw a tentative brickbat at Cory for apparently not designing the client with portability in mind as a key design and build requirement. We had already known that it wasn't inherently portable since the need to port it had been mentioned officially on numerous occasions, but we didn't know the extent of the problem.

Sadly, now we do, and it's terrifying.

Judging by the list, Phoenix was 100% right when he said that a large amount of work would be involved in the porting, requiring substantial commitment of resources which are not presently available (this work is currently resource-constrained). In other words, the failure to design the client for portability in the first place is costing Linden Labs dearly in money and resources, and is costing the Linux customer base dearly in annoyance and protracted waiting. All because of a failure in design/planning, by the chief architect.

Every single item on that list has portable solutions that have been implemented in countless fully portable games, as anyone who has been looking through the SDL and dozens of other 3D forums knows full well. It has been many years since full portability between the major platforms was regarded as a problem. The fact that large sections of the client were designed and coded to a specific platform instead of portably is technically underwhelmiing, and certainly not in keeping with the vision that makes Second Life so great.

There is really nowhere to go from here. Because of this early design failure, creating the Linux client is now a financial matter, and the platform demographics suggest that it would be a poor investment of time, money, and resource. This is a very poor state of affairs.

Interesting job spec.

I notice that:

1. "These positions report to the VP of Product Development."

2. The advert does not mention ability to design/write portable code as a requirement.

Perhaps the two things are connected? Phoenix's list would tend to support that.

Hmm you are leaving the parts out that actually say the code is _mostly_ portable. And the big problem is Developer resources.. Also I dont think it is costing them money by not developing a Linux port up front it would have cost more to support more platforms from the start of SL till now. So by not having a Linux port until there is suitable demand actually saves them money. All and all I took Pheonix post as hopeful. Yes I am a Linux Systems Admin by day. I would love to see a Linux port. And from what he said if they spend the resources on it(IE Hire more programmers now) it could happen. But of course I am not holding my breath. They need to stablize the existing ports.... In the meantime lets makes sure linux is not totally forgotten by bringing it up after every major release without it.

Heres to a Linux port by 2.0!

Kala

That's not actually meaningful. Of course C/C++ is _mostly_ portable, that's inherent in the language. And of course the open-source libraries used by the client are portable too, that's in the nature of FOSS.

Yet despite that, the client as a whole is non-portable because parts of it were coded without multi-platform operation in mind --- the Hotline info is very clear on that. And that's very bad, because it requires far more effort to fix non-portabilities later during a port than to do the work only once up front, in a portable manner.

Developing portably and releasing are two different things.

You can design a system in a portable manner, making it buildable for any of the major platforms, without necessarily releasing all the builds for which it compiles and therefore without necessarily incurring any support costs for those additional platforms.

It's all in the design of the build system and portable coding practices, nothing else. If that had been done from the start with the same foresight about future platforms as the company has future vision, the Linux client would be available for release now, with near-zero additional work.

its gonna be ok, by the time they do figure out how to port it someone else will enter the market with real postix support along with other major platforms (including the wanna be pc game consoles comming out soon). then LL wont have to worry about anything on sl ever again

Sadly, I think that you're right, Osgeld.

If LL wait until an open-source competitor appears, it'll be far too late for them to retain the lead, but it seems that they don't realize that. It's not possible to compete against X thousand unpaid developers, whoever you are.

The only way for LL to be reasonably certain of a strong position (not necessarily a lead) in a distributed metaverse is by seeding it early on in a way that is favourable to them. But they're not doing that, and apparently don't plan to do so.

The seeding would have to include:

1. the distribution protocol (streaming from players' authoritative worlds on their PCs up to the central big-iron caches, and streaming from the caches down to the clients)
   
   
2. the open-source client itself (because otherwise people will develop other clients using other protocols, and LL will be left out on a limb)
   
   
3. the content creation tools (because otherwise people will develop their own and the result won't be compatible with LL's streaming protocol)
   

It's rather pointless talking about it though, given that none of the above is on the cards at all. So I think that you're right --- LL has a great concept, but the company is going to sink without trace owing to not following through on what needs doing.