How exactly will Linux support be implemented?

[imatechguy]

Title says it all. As a Linux only user I was beyond pleased when I discovered this project and found that it would come not only DRM free but also with Linux support. I haven't seen it mentioned in the announcements or updates so I'd like to have some official word on the plan for distributing Linux versions of the game.

 

 

Thank you.

[Elerond]

http://www.kickstarter.com/projects/obsidian/project-eternity/posts/313192

 

http://eternity.obsidian.net/

 

Unity 4 engine what project eternity will use support Windows, Mac and Linux platforms.

[imatechguy]

http://www.kickstart...ty/posts/313192

 

http://eternity.obsidian.net/

 

Unity 4 engine what project eternity will use support Windows, Mac and Linux platforms.

 

I guess I need to rephrase to be more clear that I'm interested in delivery method more than creation method. Your links do tell me how they'll build the game but I want to know if the Linux version will be tied to Steam, will I get a tarball, .rpm, .deb, etc file to download or something else?

 

 

Thank you.

 

 

EDIT: typo and clarification

Edited October 4, 2012 by imatechguy

[Elerond]

In my opinion Desura could be their best bet for linux/mac distribution for non-steam version (aka drm-free version)

[Sensuki]

I remember hearing the phrase "Tarball Knights of Gzippa" or something like that

[imatechguy]

I'm not sure what file type mac folks need for installation but I'd rather not have anything like Desura involved, though on the surface it looks better than Steam as an option. If the windows guys can get a setup.exe file from GOG I'd like to get the equivalent. What about those that have pledged at a level where they get a boxed/disc version? I'd be very disappointed to find out my "disc" was a platform program that I needed to install before getting the game itself.

 

 

Thank you.

[Waywocket]

I doubt they're likely to know for some time. A this stage we don't even know what delivery mechanisms Unity will support for Linux, or if that entire problem is left to the individual developer.

 

(Of course the engine choice doesn't mandate any particular method, but if for example the IDE has a 'click here to build Ubuntu package' button, then that's the kind of thing that might be an influencing factor. For what little it's worth, the only Unity game I know with a published Linux version is Rochard, which is distributed as 64/32-bit tarballs. That might be taken to imply that the Unity IDE doesn't have a built-in method of generating anything more specific, but who can say.)

[anek]

@Waywocket

 

If I'm not mistaken, Unity's Linux support is also pretty new, so who knows what things will be like in 2014 when PE gets released. (Note that Obsidian has announced that they will be using version 4 of Unity, which is not even available yet.)

Edited October 4, 2012 by anek

[moridin84]

http://www.kickstart...ty/posts/313192

 

http://eternity.obsidian.net/

 

Unity 4 engine what project eternity will use support Windows, Mac and Linux platforms.

 

I guess I need to rephrase to be more clear that I'm interested in delivery method more than creation method. Your links do tell me how they'll build the game but I want to know if the Linux version will be tied to Steam, will I get a tarball, .rpm, .deb, etc file to download or something else?

Ummm, why do you want to know anyway?

[imatechguy]

Ummm, why do you want to know anyway?

 

Simply put I won't install Steam or any other "distribution service" to play a game and I don't have windows on any computer I own so I'd like to know if those of us who are Linux users will have an installation option equivalent to what windows users that choose the DRM free GOG option. I'd just like an explanation of what the PE team and Obsidian consider "Linux support".

 

There is no guarantee any 'doze program will run in WINE so while some may point to that it's really just a potential option at best.

 

 

 

Thank you.

[Elerond]

Feargus said in kickstarter comments that they don't yet know how they will distribute drm-free version to mac and linux. Although he said that he hopes that GOG will offer it's services for all platform when game is due.

 

And GOG upcoming announcement about that they are bringing their catalog to new OS gives some hope that it's possible that GOG will be drm free version's distributor for all platforms.

 

http://www.gog.com/news/come_watch_cd_projekt_red_and_gogcom_special_event

[veryblackraven]

Steam is coming to Linux very soon (at least to Ubuntu).

I'd prefer Obsidian to sell Project Eternity via as much stores as possible.

Steam, Desura, Indievania, IndieCity, GamersGate... The more of them the better.

[pseudonymous]

I guess I need to rephrase to be more clear that I'm interested in delivery method more than creation method. Your links do tell me how they'll build the game but I want to know if the Linux version will be tied to Steam, will I get a tarball, .rpm, .deb, etc file to download or something else?

 

To be perfectly honest, rpm and deb would be the worst possible move they could make for linux users, it would be as wonderful an idea as the loki installer, which gave everyone an awesome graphical installer that looked great, until glibc no longer supported the features used in the installer and gtk 1 was dropped from a distribution which crapped out any attempt at running the installer as it was intended to work. That event left people wondering how to install their games through the shell commands of make self (which the loki installer was just a gui-wrapper for).

 

In 10 years Obsidian is not going to repackage the game so you can play it on Ubuntu farting ferret, and you'll want to play the game, however dpkg will barf on a deb made on the current Ubuntu lactating lemur release (RPM has the same problems and worse given the various incompatible forks of the RPM project).

 

So, until the open source community figures out that backwards compatibility and interoperability between distributions are important features of the consumer desktop, you should stick to asking for tarballs or Steam which will hopefully include the dependencies of the game.

 

This, of course, is assuming Valve doesn't go bankrupt like every other company that has attempted to support consumer oriented linux.

[imatechguy]

I guess I need to rephrase to be more clear that I'm interested in delivery method more than creation method. Your links do tell me how they'll build the game but I want to know if the Linux version will be tied to Steam, will I get a tarball, .rpm, .deb, etc file to download or something else?

 

To be perfectly honest, rpm and deb would be the worst possible move they could make for linux users, it would be as wonderful an idea as the loki installer, which gave everyone an awesome graphical installer that looked great, until glibc no longer supported the features used in the installer and gtk 1 was dropped from a distribution which crapped out any attempt at running the installer as it was intended to work. That event left people wondering how to install their games through the shell commands of make self (which the loki installer was just a gui-wrapper for).

 

In 10 years Obsidian is not going to repackage the game so you can play it on Ubuntu farting ferret, and you'll want to play the game, however dpkg will barf on a deb made on the current Ubuntu lactating lemur release (RPM has the same problems and worse given the various incompatible forks of the RPM project).

 

So, until the open source community figures out that backwards compatibility and interoperability between distributions are important features of the consumer desktop, you should stick to asking for tarballs or Steam which will hopefully include the dependencies of the game.

 

This, of course, is assuming Valve doesn't go bankrupt like every other company that has attempted to support consumer oriented linux.

 

Well if we get a choice source would be best but we'll never get that; and while .tar would cover everyone I'd be okay with a binary option. However I can work with .deb or .rpm to create a PKGBUILD now if I have to and just hold onto it. Steam is not an option.

 

Regarding backwards compatibility and interoperability... We have that to a degree, some distro's more than others, but I feel that's really up to the Dev's and each distro's philosophy, with some onus on the user to learn what options they have. I'd rather not see my chosen distro affected by those that want a pretty gui for everything and don't care about the backend, or by those that only care about the backend and eschew gui's. That's the beauty of open source, there's something for everyone and when you're tired of what you're using grab something new. If you like your distro there's no reason to change, but that doesn't mean you can't look around with Vbox/VMware or on a few extra partitions.

 

Back on topic: Linux support = GOOD. I was just wondering what file format was currently being planned for the actual distrobution of the game.

[Archmage Silver]

Back on topic: Linux support = GOOD. I was just wondering what file format was currently being planned for the actual distrobution of the game.

Obsidian is still considering their options in regards to the digital distribution of the Linux version of Project Eternity. Someone mentioned Desura to Feargus on Kickstarter, and he said they'd take a look at that as well as other options. There's no tangible info on the actual file format as of yet though.

[Waywocket]

I guess I need to rephrase to be more clear that I'm interested in delivery method more than creation method. Your links do tell me how they'll build the game but I want to know if the Linux version will be tied to Steam, will I get a tarball, .rpm, .deb, etc file to download or something else?

 

To be perfectly honest, rpm and deb would be the worst possible move they could make for linux users, it would be as wonderful an idea as the loki installer, which gave everyone an awesome graphical installer that looked great, until glibc no longer supported the features used in the installer and gtk 1 was dropped from a distribution which crapped out any attempt at running the installer as it was intended to work. That event left people wondering how to install their games through the shell commands of make self (which the loki installer was just a gui-wrapper for).

 

In 10 years Obsidian is not going to repackage the game so you can play it on Ubuntu farting ferret, and you'll want to play the game, however dpkg will barf on a deb made on the current Ubuntu lactating lemur release (RPM has the same problems and worse given the various incompatible forks of the RPM project).

 

So, until the open source community figures out that backwards compatibility and interoperability between distributions are important features of the consumer desktop, you should stick to asking for tarballs or Steam which will hopefully include the dependencies of the game.

 

This, of course, is assuming Valve doesn't go bankrupt like every other company that has attempted to support consumer oriented linux.

 

This post is complete nonsense almost in its entirety. Pretty much the only valid point is that specialised installers are generally a bad idea, but using standardised packaging methods are the solution to that problem, and to equate those two things is a grotesque mischaracterisation.

 

A deb or rpm package is the moral equivalent of a tarball, plus a manifest that allow the package manager to know what files have been put where, so it can do things like uninstalling, upgrading, and checking that no other package tries to overwrite those files. A package can also specify that it depends on some other software, typically libraries that are dynamically linked into the application, and it can specify the version(s) that it requires. When you try installing a package and it produces dependency errors, that means that the package in question declares a dependency on something you don't have. If you just had a tarball, that wouldn't magically make the dependency go away; it would just mean that you don't know about it until you try to run the program and it crashes.

 

 

The best way to improve backwards compatibility is to statically link the libraries used where possible, and include whatever dependencies you need in your package; that's a completely orthogonal issue to the packaging format used - if you can make a tarball whose contents have no external dependencies, then you can make a package with no external dependencies, only now you have the benefit that the package manager knows about your software.

 

(BTW glibc has never broken backward compatibility, nor has the deb format TTBOMK; I'd be very surprised if rpm ever has.)

[pseudonymous]

This post is complete nonsense almost in its entirety. Pretty much the only valid point is that specialised installers are generally a bad idea, but using standardised packaging methods are the solution to that problem, and to equate those two things is a grotesque mischaracterisation.

 

Way to take a critical view of your favorite platform.

 

A deb or rpm package is the moral equivalent of a tarball, plus a manifest that allow the package manager to know what files have been put where, so it can do things like uninstalling, upgrading, and checking that no other package tries to overwrite those files. A package can also specify that it depends on some other software, typically libraries that are dynamically linked into the application, and it can specify the version(s) that it requires. When you try installing a package and it produces dependency errors, that means that the package in question declares a dependency on something you don't have. If you just had a tarball, that wouldn't magically make the dependency go away; it would just mean that you don't know about it until you try to run the program and it crashes.

 

In ten years, will you be the first in line explaining to each and everyone of the linux users how to extract the game from the debs and rpms they purchased when package names change and both dpkg and rpm can't find the dependencies? No? Maybe tarballs with dependencies included aren't a bad idea after all... A little common sense practicality now will make everyone's future enjoyment of the game that much easier.

 

(BTW glibc has never broken backward compatibility, nor has the deb format TTBOMK; I'd be very surprised if rpm ever has.)

 

As an exercise in awesome, try installing and playing any of the games Loki software ported on a modern distribution, xlib and libc errors galore. For extra awesome: try extracting the source from any src.rpm from Fedora 17 with the rpm in Cent 5 (and vice-versa, of course). It's fun, you should try it sometime.

Edited October 12, 2012 by pseudonymous

[Waywocket]

This post is complete nonsense almost in its entirety. Pretty much the only valid point is that specialised installers are generally a bad idea, but using standardised packaging methods are the solution to that problem, and to equate those two things is a grotesque mischaracterisation.

 

Way to take a critical view of your favorite platform.

FWIW, Windows is my favourite platform. Certainly for games anyway.

A deb or rpm package is the moral equivalent of a tarball, plus a manifest that allow the package manager to know what files have been put where, so it can do things like uninstalling, upgrading, and checking that no other package tries to overwrite those files. A package can also specify that it depends on some other software, typically libraries that are dynamically linked into the application, and it can specify the version(s) that it requires. When you try installing a package and it produces dependency errors, that means that the package in question declares a dependency on something you don't have. If you just had a tarball, that wouldn't magically make the dependency go away; it would just mean that you don't know about it until you try to run the program and it crashes.

 

In ten years, will you be the first in line explaining to each and everyone of the linux users how to extract the game from the debs and rpms they purchased when package names change and both dpkg and rpm can't find the dependencies? No? Maybe tarballs with dependencies included aren't a bad idea after all... A little common sense practicality now will make everyone's future enjoyment of the game that much easier.

 

(BTW glibc has never broken backward compatibility, nor has the deb format TTBOMK; I'd be very surprised if rpm ever has.)

 

As an exercise in awesome, try installing and playing any of the games Loki software ported on a modern distribution, xlib and libc errors galore. For extra awesome: try extracting the source from any src.rpm from Fedora 17 with the rpm in Cent 5 (and vice-versa, of course). It's fun, you should try it sometime.

 

Did you even read any of what I wrote? Did you understand any of it? I don't understand how you can make exactly the same mistakes again.

Edited October 12, 2012 by Waywocket

[vv221]

Please, no distribution-specific packaging (.deb, .rpm and so on) !

A tarball, a README, it can work everywhere, at any time !

[Zeyelth]

Whatever method they use for distribution, unless the distributor provides updated packages and a client which takes care of the execution details, I prefer tarballs. Tarballs complete with any needed libraries included, and a shellscript which you use to execute it.

 

Why? When the included libraries no longer work because they're out of date, you can simply install new ones and tell the shellscript to use them instead. Such tarballs can also be dropped in the home directory, and executed, without cluttering the rest of the system with random files. Furthermore, if you really wanted to, you could roll your own distribution specific package, most of them are little more than zip-files with instructions on where to place files and a list of dependencies anyway...

 

Oh, and for users who aren't that savvy, they will likely only run into issues when the libraries stop working, and with a tarball, it would be fairly trivial for the community to provide an updated shellscript.

Edited October 14, 2012 by Zeyelth

[sonil]

Please, no distribution-specific packaging (.deb, .rpm and so on) !

A tarball, a README, it can work everywhere, at any time !

 

ye!that's what we REALLY need! .deb package is a bad way for games.

[norg]

If you look into the HumbleBundle they have several ways of distribution, most of the games are just tar.gz and some also support .deb and .rpm. The minor have .bin or just a great .sh file. I would prefer the tar.gz file, but i'm also fine with .bin/.sh.

I guess it's no big deal to offer more ways, and i think desura is nice, but i prefer not to depend on a plattform so i would love .tar.gz as i can use it on my primary workstation with Gentoo (hey a ebuild would be awesome and also with LFS and Slackware.

 

I hope they will use the beta time to deal with this issues, so we can help them.

[nikolokolus]

Ummm, why do you want to know anyway?

 

Simply put I won't install Steam or any other "distribution service" to play a game and I don't have windows on any computer I own so I'd like to know if those of us who are Linux users will have an installation option equivalent to what windows users that choose the DRM free GOG option. I'd just like an explanation of what the PE team and Obsidian consider "Linux support".

 

There is no guarantee any 'doze program will run in WINE so while some may point to that it's really just a potential option at best.

 

 

 

Thank you.

 

You'll probably either get a .bin file that can installed in bash or maybe they'll distrubute a .deb or a .rpm file? In any case they've promised a DRM free option at the time of release if you don't want to use Steam (which is coming to Linux) or if GOG.com doesn't yet have Linux support at that time. Why are you sweating this now? It will sort itself out.

[Setlec]

why not use mojosetup like most of the id software's linux ported games? it's better than having a boring and stupid flamewar about rpm vs deb.

[Humanoid]

The GoG Linux support thing is probably a bit of a red herring anyway: official GoG support for Linux, if and when it comes, would essentially be the GoG crew's inhouse tweaking of catalogue titles to be able to run in Linux, much in the same way they tweak them now to be able to run in Windows 7 and MacOS. It's not really related at all to Eternity, where presumably it will be Obsidian and not GoG who do the compatibility work - the latter only needing to make the provided files available for download, i.e. business as usual.