Linux Expectation Management
by Jeff Tunnell · 11/23/2005 (1:14 pm) · 78 comments
I hope this post does not turn into a huge flame war, but it is time to address some of the issues surrounding Linux, and GarageGames' future support of this operating system. Before causing too much panic, we are not dropping support, but we need to manage expectations.
First off. We love Linux, and hope we have done more, percentage wise, than nearly any other company on the planet to support it (other than those whose business model revolves around it, of course).
Secondly. Most of the heavy lifting for originally getting TGE running on Linux and keeping it up to date fell to John Quigley (later hired by Bravetree, and now an employee of GarageGames), but John no longer wishes to work on TGE Linux.
Third. Linux does not love back. Too many distros. Much incompatibility. Moving target. Not much community support from Linux users coming back to Torque. Little to no revenue (less than 3% of what we do). Little to no love from the Linux community for our efforts.
These are simply facts. I'm sure there will be some questioning of my statements, but they are true from our point of view, and they are causing enough pressure that we need to do something about it.
I would like to start a dialog about solutions to the problems. In the meantime, my suggestions are as follows:
1. Torque is cross platform, but Linux support will lag behind a point release or two. We can manage expectations by saying this upfront in our product pages.
2. In all product pages we should say that using Linux on Torque requires an advanced programmer that understands Linux and the build process in depth, i.e. the build process is unsupported.
3. If members of the community feel that Linux Torque needs to be at the latest point release, and run across a broad spectrum of distros, we would be happy to set up secure SVN, allow them to do the work and roll the changes back into the main code tree.
For the far future, some of the development of our technologies are being developed on Linux boxes. Additionally, the distros get better all the time, so the problem set may get smaller. Cross platform is a religion for us, and we like the idea of supporting Linux, so we hope to bring Linux everything out in a timely manner and up to our quality standards.
What do you think? Please be gentle.
-Jeff Tunnell, GG
First off. We love Linux, and hope we have done more, percentage wise, than nearly any other company on the planet to support it (other than those whose business model revolves around it, of course).
Secondly. Most of the heavy lifting for originally getting TGE running on Linux and keeping it up to date fell to John Quigley (later hired by Bravetree, and now an employee of GarageGames), but John no longer wishes to work on TGE Linux.
Third. Linux does not love back. Too many distros. Much incompatibility. Moving target. Not much community support from Linux users coming back to Torque. Little to no revenue (less than 3% of what we do). Little to no love from the Linux community for our efforts.
These are simply facts. I'm sure there will be some questioning of my statements, but they are true from our point of view, and they are causing enough pressure that we need to do something about it.
I would like to start a dialog about solutions to the problems. In the meantime, my suggestions are as follows:
1. Torque is cross platform, but Linux support will lag behind a point release or two. We can manage expectations by saying this upfront in our product pages.
2. In all product pages we should say that using Linux on Torque requires an advanced programmer that understands Linux and the build process in depth, i.e. the build process is unsupported.
3. If members of the community feel that Linux Torque needs to be at the latest point release, and run across a broad spectrum of distros, we would be happy to set up secure SVN, allow them to do the work and roll the changes back into the main code tree.
For the far future, some of the development of our technologies are being developed on Linux boxes. Additionally, the distros get better all the time, so the problem set may get smaller. Cross platform is a religion for us, and we like the idea of supporting Linux, so we hope to bring Linux everything out in a timely manner and up to our quality standards.
What do you think? Please be gentle.
-Jeff Tunnell, GG
About the author
#2
1. Makes me kinda a sad, and 2. is so true.
3. That sounds like a great idea GG doesn't have the resources considering the $$ they get back from the platform but a community approach would make sense. I know that i would like the releases to be more evenly matched as problably mainy other linux developers. Note the thing with Linux is you have to identify a baseline that you can say you will support. Here at work (video hardware manufacturer) we boiled it down to rpm based distros supportting glibc 2.3.2 and above and gcc 3.2.x, gcc 3.3.x, and gcc 3.4.x (though technically we build using glibc 2.2.5, and wille eventually add gcc4xx). This covers 80% of whats currently available. There are a number of people on the forums that would probably help out if GG provided that kind of support for a community based initiative. I know i would chip in.
Craig: The linux market is indeed very small, though somewhat vocal at times :) but as a developper i do all of my work under linux and make sure that most of what i code is portable (as much as is possible). Whether or not i actually sell for that market doesn't mean much but i want very much to be able to work with the platform. Seeing that the toolchain used there can be use for mac and windows and that its costs are near zero makes it a no brainer for my needs.
11/23/2005 (1:48 pm)
Unfortunately thems are the facts. Here's waht i think :1. Makes me kinda a sad, and 2. is so true.
3. That sounds like a great idea GG doesn't have the resources considering the $$ they get back from the platform but a community approach would make sense. I know that i would like the releases to be more evenly matched as problably mainy other linux developers. Note the thing with Linux is you have to identify a baseline that you can say you will support. Here at work (video hardware manufacturer) we boiled it down to rpm based distros supportting glibc 2.3.2 and above and gcc 3.2.x, gcc 3.3.x, and gcc 3.4.x (though technically we build using glibc 2.2.5, and wille eventually add gcc4xx). This covers 80% of whats currently available. There are a number of people on the forums that would probably help out if GG provided that kind of support for a community based initiative. I know i would chip in.
Craig: The linux market is indeed very small, though somewhat vocal at times :) but as a developper i do all of my work under linux and make sure that most of what i code is portable (as much as is possible). Whether or not i actually sell for that market doesn't mean much but i want very much to be able to work with the platform. Seeing that the toolchain used there can be use for mac and windows and that its costs are near zero makes it a no brainer for my needs.
#3
11/23/2005 (2:05 pm)
Don't worry Jeff... this isn't /. :P 
#4
11/23/2005 (2:08 pm)
I agree with the #3 Route. Isn't that the methodology that Linux was built on. I'm no fan of Linux but I know many are and I hope that the Linux guys here go with option 3. I hope they also understand the position that GG is in. 
#5
11/23/2005 (2:09 pm)
Benoit, I feel you may be forgetting that most of the 'rest of' the tool chain (ie artist tools etc) are primarily windows and/or mac based. So at nearly all points during development you need to really have a windows build going. Obviously that entails having windows anywho... Admitedly theres the sheer factor of just wanting to develop under Linux :D Which as you so rightly put is a "no brainer" in some circumstances. 
#6
1. As long as GG tags the linux release as significantly different, I don't see it being a major issue. Linux developers can download the latest and greatest (SVN as in number 3 or the official download), and diff according to the latest and greatest Win/OSX download. Bandwidth consumption doubles on both ends as the user has to download multiple versions and then locate the differences, but if the linux market is a key area, this could be a strong place to gain associates.
2. I think that is an excellent idea. I would also recommend bolding a similar notice in the engine programming segments for TSE and TGE as we still see a number of "3D Gamestudio maked this easier" or "Unity makes that nicer" comments from non-programmers. Of course, I don't know how to make people read something before purchasing it, either.
3. Again, I think this could help integrate some new associates into the GG fold. Having associates with linux expertise and hooks in other linux communities could definitely help as well.
11/23/2005 (2:10 pm)
Considering the metrics that you're working with, it makes sense. I can see this plan generating a lot of "OMG GG STOPS SUPPORTING LINUX!" rumors, though. Look at how prevalent the $500,000 commercial license rumor still is on other gaming sites when a cursory glance at the product page dispells it completely (and has for a long time now).1. As long as GG tags the linux release as significantly different, I don't see it being a major issue. Linux developers can download the latest and greatest (SVN as in number 3 or the official download), and diff according to the latest and greatest Win/OSX download. Bandwidth consumption doubles on both ends as the user has to download multiple versions and then locate the differences, but if the linux market is a key area, this could be a strong place to gain associates.
2. I think that is an excellent idea. I would also recommend bolding a similar notice in the engine programming segments for TSE and TGE as we still see a number of "3D Gamestudio maked this easier" or "Unity makes that nicer" comments from non-programmers. Of course, I don't know how to make people read something before purchasing it, either.
3. Again, I think this could help integrate some new associates into the GG fold. Having associates with linux expertise and hooks in other linux communities could definitely help as well.
#7
11/23/2005 (2:16 pm)
Craig: Not true i build and test windows builds right in Linux. I even maintain cross-compilation scripts for that purpose. And when Macs move to intel based system it should be possible to easily support it all from one environment. As for graphics for serious use there is Maya and Houdini and XSI available for the platfrom (though not many have recompiled the plugins for that environement). For the lower end there is blender.
#8
The main issue here is coordinating work from the long time linux users of TGE (I've been using it since it first compiled on Linux, used v12 on windows before that) and GG. I'm sure Ben and others are swamped with patches from here and there and coordinating this job isn't very easy. So there's got to be something to do to make the burden a bit less tedious.
Personally I think some parts of the platform code need to be cleared up, there's many things in common with the MacOSX platform and the *NIX platform that could make it a lot simpler to mantain different platforms. Torque is big enough to start worrying about reusing code rather than duplicating effort. Many things that were done for the Mac 1.4rc2 release (I can't remember the name of who did it now) where similar to what we had to do for UNIX, and (I'm not sure here) but they might be similar on windows.
I would be really sad to see Torque dropping Linux support and I would love to do whatever it takes to keep it the way it is.
As for distros, it's not really that hard to make it work in several distibutions, but it's also not straightforward. I could write an article on things to keep in mind and how to do it so that libc++ or sdl or openal don't become problems. John Q. did a great job a while back adding support for a local lib directory that made it easy to run the game on several distros, and we've been succesfull at doing so with Flash Bios this far. Other commercial Linux games do similar things (Like doom3) and run on any distro, at least I haven't had problems running it in a couple of boxes with the same binary installer.
There's definetly work to do, just kinda messy to start on it. But there are tools to do this painless, there's BitRock (which you guys are already using), there's a nice lib dir and there's a nice loki made startup script that favours libs in the lib dir. It's definetly better than it was a couple of years ago, the only issue I keep getting annoyed about is supporting new gcc versions, the compiler changes a couple of lil things but that are used extensively in TGE and you have a big problem on-hands.
Anyway, I won't bother you any more.
Regards,
Xavier.
11/23/2005 (2:19 pm)
@Jeff: Me and Ron worked hard on getting 1.4 to compile on Linux, as a matter of fact, I had a patch that made 1.4rc1 compile but that never got applied to HEAD, it was only applied after me and Ron coordinated on getting 1.4rc2 working and he used my patch as a start point, then added unicode support and probably some other things that I can't recall and got it working. I'm not sure all this stuff is in HEAD either yet, although I do have an SDK installer that works out of the box.The main issue here is coordinating work from the long time linux users of TGE (I've been using it since it first compiled on Linux, used v12 on windows before that) and GG. I'm sure Ben and others are swamped with patches from here and there and coordinating this job isn't very easy. So there's got to be something to do to make the burden a bit less tedious.
Personally I think some parts of the platform code need to be cleared up, there's many things in common with the MacOSX platform and the *NIX platform that could make it a lot simpler to mantain different platforms. Torque is big enough to start worrying about reusing code rather than duplicating effort. Many things that were done for the Mac 1.4rc2 release (I can't remember the name of who did it now) where similar to what we had to do for UNIX, and (I'm not sure here) but they might be similar on windows.
I would be really sad to see Torque dropping Linux support and I would love to do whatever it takes to keep it the way it is.
As for distros, it's not really that hard to make it work in several distibutions, but it's also not straightforward. I could write an article on things to keep in mind and how to do it so that libc++ or sdl or openal don't become problems. John Q. did a great job a while back adding support for a local lib directory that made it easy to run the game on several distros, and we've been succesfull at doing so with Flash Bios this far. Other commercial Linux games do similar things (Like doom3) and run on any distro, at least I haven't had problems running it in a couple of boxes with the same binary installer.
There's definetly work to do, just kinda messy to start on it. But there are tools to do this painless, there's BitRock (which you guys are already using), there's a nice lib dir and there's a nice loki made startup script that favours libs in the lib dir. It's definetly better than it was a couple of years ago, the only issue I keep getting annoyed about is supporting new gcc versions, the compiler changes a couple of lil things but that are used extensively in TGE and you have a big problem on-hands.
Anyway, I won't bother you any more.
Regards,
Xavier.
#9
11/23/2005 (2:28 pm)
Xavier: Indeed, nicely put.
#10
First off, thanks for bringing this under the attention of the community in this clear and open way. I really appreciate the fact that you want input from the community about this.
I totally understand that bringing in money to support the development effort is an important factor in deciding whether or not to support (and the degree in which to support) a product and/or platform. After all, nobody wins if wasted effort leads to loss of quality or products on a broader scale.
However, Linux (independent of a specific distro) is becoming more and more of a desktop platform in addition to it's server platform uses. That is one of the reasons I find Linux so attractive, even still in days such as these where Microsoft wants to blow the world away with their multimedia centered Vista (this is not a flame towards Microsoft). And I think it's awesome that an engine with the proportions and quality of Torque is able to run on this system (that would be Linux :p).
That said, one must admit that Linux still is a secondary desktop operating system for a lot of users out there, if they use it at all. And therefore most effort of most developers will still go to the other more popular (among your casual user) operating systems. I have no problems if Torque for Linux would lag behind a few releases if this means that Torque for Linux will still be supported. I just hope that "lagged" will not mean "eventually cancelled".
If GarageGames would decide to make Torque for Linux a "lagging" release, your proposed points #1 and #2 are fine in my point of view since they are most clear towards current and new/potential users. #3 Would be an excellent opportunity to shift some of the work required to get Torque for Linux ready for release, from GarageGames (who understandibly needs attention for more popular platforms) to the developers that actually need Torque for Linux. After all, if they really need it, they will probably make those changes anyway. So why not make it easy for them to roll those changes back to the official release so that with a next update, their changes will still be there?
There is one point of concern about this, though. A lot of multiplayer games have seperate dedicated server versions of their game released. And to be honest, I'd rather run such a server on a Linux or BSD box than on Windows. Not just for security issues, but also for the obvious cost issues (just have a look at the price list of a random ISP). So maybe it would be an idea to split the Torque for Linux product into two seperate branches: a lagged, complete torque build. And a full, (almost) up to date dedicated server build. I don't know the Torque architecture well enough to know if this is feasible, but it sure should be something to consider.
I also think the idea Benoit mentioned is something worth thinking about: making the linux build supported on linux installations with specific package installations (such as specific versions of gcc, suppport libraries etc.) only. That would limit the scope of linux build modifications.
Btw, does this mean that Constructor for Linux will also be lagged?
Lastly,
Many thanks to all the hard work John Quigley (and the other contributors) put into the linux build. It is much appreciated!
Anyway,
my two cents.
Regards,
Thijs
11/23/2005 (2:38 pm)
Hi Jeff,First off, thanks for bringing this under the attention of the community in this clear and open way. I really appreciate the fact that you want input from the community about this.
I totally understand that bringing in money to support the development effort is an important factor in deciding whether or not to support (and the degree in which to support) a product and/or platform. After all, nobody wins if wasted effort leads to loss of quality or products on a broader scale.
However, Linux (independent of a specific distro) is becoming more and more of a desktop platform in addition to it's server platform uses. That is one of the reasons I find Linux so attractive, even still in days such as these where Microsoft wants to blow the world away with their multimedia centered Vista (this is not a flame towards Microsoft). And I think it's awesome that an engine with the proportions and quality of Torque is able to run on this system (that would be Linux :p).
That said, one must admit that Linux still is a secondary desktop operating system for a lot of users out there, if they use it at all. And therefore most effort of most developers will still go to the other more popular (among your casual user) operating systems. I have no problems if Torque for Linux would lag behind a few releases if this means that Torque for Linux will still be supported. I just hope that "lagged" will not mean "eventually cancelled".
If GarageGames would decide to make Torque for Linux a "lagging" release, your proposed points #1 and #2 are fine in my point of view since they are most clear towards current and new/potential users. #3 Would be an excellent opportunity to shift some of the work required to get Torque for Linux ready for release, from GarageGames (who understandibly needs attention for more popular platforms) to the developers that actually need Torque for Linux. After all, if they really need it, they will probably make those changes anyway. So why not make it easy for them to roll those changes back to the official release so that with a next update, their changes will still be there?
There is one point of concern about this, though. A lot of multiplayer games have seperate dedicated server versions of their game released. And to be honest, I'd rather run such a server on a Linux or BSD box than on Windows. Not just for security issues, but also for the obvious cost issues (just have a look at the price list of a random ISP). So maybe it would be an idea to split the Torque for Linux product into two seperate branches: a lagged, complete torque build. And a full, (almost) up to date dedicated server build. I don't know the Torque architecture well enough to know if this is feasible, but it sure should be something to consider.
I also think the idea Benoit mentioned is something worth thinking about: making the linux build supported on linux installations with specific package installations (such as specific versions of gcc, suppport libraries etc.) only. That would limit the scope of linux build modifications.
Btw, does this mean that Constructor for Linux will also be lagged?
Lastly,
Many thanks to all the hard work John Quigley (and the other contributors) put into the linux build. It is much appreciated!
Anyway,
my two cents.
Regards,
Thijs
#11
The Master Server source code is included in TNL. You could utilize that on linux. I'm not sure how many of 1.4's updates have been in the netcode area or how it will fold into TNL, but that's always an option.
11/23/2005 (2:52 pm)
@ThijsThe Master Server source code is included in TNL. You could utilize that on linux. I'm not sure how many of 1.4's updates have been in the netcode area or how it will fold into TNL, but that's always an option.
#12
Also, I am sorry that I did not include thanks to Ron and Xavier for the current Linux support they have been giving us. If they are up to the task, they would be ideal to lead the community Linux team:)
Keep the comments coming. After a couple of days (don't forget this is a holiday weekend in the USA), we will attempt to summarize the comments and have some action items to move forward on this issue.
-Jeff Tunnell, GG
11/23/2005 (3:02 pm)
Thanks so much for the thoughtful posts. Let me make it perfectly clear. GarageGames is not dropping support for Linux. We are simply trying to manage expectations. Ideally, Option #3 where we help the community make support easier would be the best option. Also, I am sorry that I did not include thanks to Ron and Xavier for the current Linux support they have been giving us. If they are up to the task, they would be ideal to lead the community Linux team:)
Keep the comments coming. After a couple of days (don't forget this is a holiday weekend in the USA), we will attempt to summarize the comments and have some action items to move forward on this issue.
-Jeff Tunnell, GG
#13
We are working closely with Ron to make sure that we will have a version of Constructor running on Linux. Whether or not it will be available right at launch remains to be seen (it would be silly to delay the launch significantly just to wait for the linux version) but we very much understand the lack of good brush editors on Linux (and Mac).
11/23/2005 (3:13 pm)
Quote:Btw, does this mean that Constructor for Linux will also be lagged?
We are working closely with Ron to make sure that we will have a version of Constructor running on Linux. Whether or not it will be available right at launch remains to be seen (it would be silly to delay the launch significantly just to wait for the linux version) but we very much understand the lack of good brush editors on Linux (and Mac).
#14
The way I see it, GG has the power and influence to make this concept work. Turn a specific Linux distro into a indie-game/dev OS. It wouldn't be targeted at Linux users either, since it would technically come on a bootable CD that pretty much any PC can read. It wouldn't be different from booting up games with various boot disks in the old DOS days, and from what I understand, even lower-spec systems could perform admirably well without the heavy Windows OS load.
Anybody heard of/thought about this? Just a thought anyways, thought it was relevant.
11/23/2005 (3:26 pm)
There was a discussion on http://www.gamesareart.com/ about some indies (not GG related) actually settling down with a specific Linux distro, making bootable Linux cds with indie demos built specifically for it. Unfortunately I can't find the damn forum topic again.The way I see it, GG has the power and influence to make this concept work. Turn a specific Linux distro into a indie-game/dev OS. It wouldn't be targeted at Linux users either, since it would technically come on a bootable CD that pretty much any PC can read. It wouldn't be different from booting up games with various boot disks in the old DOS days, and from what I understand, even lower-spec systems could perform admirably well without the heavy Windows OS load.
Anybody heard of/thought about this? Just a thought anyways, thought it was relevant.
#15
11/23/2005 (3:32 pm)
I have had Linux users pester me for Linux builds of one of my projects in particular, which is built onto TSE. Failing them for having Cedega, I was forced to make a TGE Legacy build of it, just so they could use WINE -- this is a pain in the neck... if there were an adequate, free interpreter for Windows->Linux... that supported DX...
#16
11/23/2005 (3:56 pm)
@Jeff: Thanks, and I would love to keep helping in whatever I can.
#17
11/23/2005 (3:58 pm)
@Mike: If you were a Linux user you wouldn't want a Windows emulator running just to use an app, native applications are much better. I don't see you running a Linux or Mac emulator on Windows to run apps from those OS's. Not that there is any emulator for windows as polished as WINE or Cedega on Linux.
#18
11/23/2005 (4:09 pm)
Jeff, I'd like to help out keeping T2D Linux happy. As there are plenty others that keep TGE running under Linux, there seems to be little to no love on the T2D side of things. As my current interests (and projects) revolve around T2D, it's beneficial to keep it up to date. I not only see T2D as a really good game engine, I also see it as Linux's solution to Macromedia Director -hence my commerical license purchase. 
#19
11/23/2005 (4:56 pm)
David, we'd like to have you help out with Linux too, if you're up for it. Sorry I hadn't got a chance to reply to your email yet. Melv and I will be in touch soon!
#20
11/23/2005 (4:58 pm)
David- Cool you should mention that. We see T2D as a Director replacement too! Keeping up the T2D Linux version for us would be a huge help. 
Associate Craig Fortune
At the end of the day, Linux just isn't for gamers, especially the casual market imo. (Feel free to flame :D)