These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Linux

 
  • Topic is locked indefinitely.
 

I am Starting A petition For Eve To make a LINUX Client!

Author
LordArcher
Red Alpha Strike
#41 - 2012-03-26 01:13:49 UTC
Banter banter banter. We all have good points. But I think, despite the way we wish it were, the truth is that Linux is not the present as was said. We aren't going to see a Linux client any time soon, not likely even if we threw 2 or 3 million dollars in CCPs face. Even if the Linux community could give the fiscal drive to CCP, it would take at least a year to 3 to get a officially supported Linux client.

So, lets not be unreasonable and focus on smaller wins shall we? In a manner of speaking we need to stand up and be counted, but we can't. the win 3.1 trick doesn't work. So rather than asking for a native/officially supported Linux client, lets focus our petitioning on what we can accomplish. we need to ask CCP and the devs for a way to mark that we use Linux. Whether it is an in game toggle or a account setting where we can check a box. It is certainly within CCP's capacity to accomplish in relatively short order and is a start for us Linux users.
Mythas Rothron
The God's of EVE Inc.
#42 - 2012-04-02 22:48:34 UTC  |  Edited by: Mythas Rothron
edit: doublepost
Mythas Rothron
The God's of EVE Inc.
#43 - 2012-04-02 22:57:05 UTC
Katrina Bekers wrote:

I know who said that.

And I confirm every word.

Which is to say that a bunch of individual developers are as supportive as it gets to help us linux nerds keep playing. But it also means that there is not any official nor "best effort" support from the company, which is who ultimately pays for the worktime development efforts.

We have many individuals to thank for their freetime support. But pressuring the company itself is not going anywhere.

Im my car analogy, one can't complain at the manufacturer. But may very well adapt the injectors to treat the home brewn concotion as fuel, and mix it to a point where the car actually runs on wine.


This.
I'm seeing all of these people who use a free/libre operating system designed to be tweaked, customized, and whatnot, and they contribute little to nothing back to the FOSS community, and they demand that a company already struggling to make it in this economy completely rewrite their main product to run on a platform that makes up only 2% of the entire desktop market.

The developers LOVE the linux OS, they have no problem tweaking their systems to get their game running on it, and they accept that their management team isn't going to pay them to build an OpenGL client.

The comments about Python are irrelevant, they contribute code and money upstream so they do more for those OSS projects than their users do.

I am a software developer. I write code for the Android Open Source Project, apps on that platform, and the linux kernel itself for the Arch project. I use a linux distro in 95% of my work, and I still totally agree with the decision not to build a native linux client. It doesn't make fiscal sense.

Also, the wine configuration is not that hard to follow, and the latest link
http://appdb.winehq.org/objectManager.php?sClass=version&iId=25544
describes which specific configurations. And google can source the rest.

What we need, is for people to contribute to some sort of project to make pulling in the libraries needed and whatnot much easier, since it seems most of the people here are sick of struggling with that. Possibly create a PlayOnLinux script?

****This is the end of the relevance of the post****

Whitehound wrote:
Still, it is irrelevant. Take all your software development knowledge and throw it away, because strictly speaking are 32bit Windows binaries when run under 64bit Windows not native either and need support to run in a 64bit environment. 32bit Windows binaries run native under Linux with WINE, because WINE Is Not an Emulator. You could go as far as saying that any software that is not a 64bit C/C++ application, which directly interfaces with the operating system and hardware, are not native applications on either Linux or Windows. Some of EVE's code was compiled with GCC some with M$V8. Why draw a line?! Even the shader code needs to be compiled by DirectX and OpenGL before it can run on the GPU. You are trying to draw a line somewhere, which serves no purpose. Your argument is pointless in this discussion, because it is not about what you see as native and lack to understand, but what gets support through CCP!


Hmm...this is right and wrong.
1) 32 bit binaries in x64 windows--this statement was completely wrong. x64 Windows does not emulate the cpu instruction set for a 32-bit processor; today's cpu's can run either code set natively, translated at the binary level. I think you're referring to the multiarch libraries, that allow the 32-bit applications to be run "natively" on a 64 bit machine.

2) Wine Is Not an Emulator--this means it's not like dosbox, translating code build for a different architecture entirely (ie an N64). Wine is an implementation of a libraries interpretation layer that, for all intents and purposes, allows Windows libraries and binaries to function on a Linux/BSD system.

3) A native application is merely an application that is compiled against/uses binary libraries on the system. So, my C++ hello world application will compile on a Windows machine using VS2010 and a linux machine with GCC, but won't function on the other system due to byte-level incompatibility (and I'll spare you the kernel explanation here).

4) Eve's game code was not compiled with GCC. It is compiled with a Microsoft compiler, and the python pieces are not compiled (it's an interpreted, or "emulated" language).

5) DX libraries are binary-compatible with Windows NT-based systems only. Nebu Retski is right, the source code of EVE O cannot be compiled on a linux distribution because it compiles against the DirectX libraries among several other pieces from the API, which aren't compiled on linux. His statement about Cedega is almost correct--Cedega just tells Wine to translate the function calls meant for the NT kernel to a format readable by the linux kernel.

So, Whitehound, your post was kind of irrelevant until the last line.
Whitehound wrote:
because it is not about what you see as native and lack to understand, but what gets support through CCP!

^^ this exactly. And CCP's management will not allow the developers to make a binary-compatible client for the Linux platform.
Katrina Bekers
A Blessed Bean
Pandemic Horde
#44 - 2012-04-03 11:10:09 UTC
OTOH, this past Fanfest (~Free Mittens!~), we noticed an important detail from CCP: for the first time in 9 years, the official sponsors of the event did NOT include Microsoft: http://fanfest.eveonline.com/en/sponsors/nvidia

At the same time, we all know how much CCP is getting involved with Sony/PS3 with Dust 514.

PS3 doesn't use DirectX and instead it uses... Blink

Won't keep my fingers crossed, but there may be some hope.

<< THE RABBLE BRIGADE >>

Caldarius Seeker
Doomheim
#45 - 2012-04-06 10:46:54 UTC
I would love to see Linux client. EVE had linux client many years ago but they switch to DX. But I don't mind. I use Windows for games and laptop with Ubuntu for work (programmer). But it would be nice to log into the game from laptop.

OR they could throw us API for stuff like mail exchange, skill queue and stuff like that. This way I could manage my character from the browser to some point just like I get notifications from my Chrome extension I build for myself.
Whitehound
#46 - 2012-04-07 20:31:28 UTC
Mythas Rothron wrote:
Hmm...this is right and wrong.
1) 32 bit binaries in x64 windows--this statement was completely wrong. x64 Windows does not emulate the cpu instruction set for a 32-bit processor; today's cpu's can run either code set natively, translated at the binary level. I think you're referring to the multiarch libraries, that allow the 32-bit applications to be run "natively" on a 64 bit machine.

I was not and still am not not talking about emulation. The problem is in the calling conventions between libraries, which needs to be worked around. There is noting native about it.

Loss is meaningful. Therefore is the loss of meaning likewise meaningful. It is the source of all trolling.

Bent Barrel
#47 - 2012-04-10 12:52:22 UTC
Whitehound wrote:
Mythas Rothron wrote:
Hmm...this is right and wrong.
1) 32 bit binaries in x64 windows--this statement was completely wrong. x64 Windows does not emulate the cpu instruction set for a 32-bit processor; today's cpu's can run either code set natively, translated at the binary level. I think you're referring to the multiarch libraries, that allow the 32-bit applications to be run "natively" on a 64 bit machine.

I was not and still am not not talking about emulation. The problem is in the calling conventions between libraries, which needs to be worked around. There is noting native about it.


but that's just mode changing in the dynamic library loader ... a 32bit app cannot load a 64bit library and vice versa, so NO translation is needed. you need a complete 32bit environment for an 32bit application to run on 64 bit OS. Mythas is correct on that part.
Whitehound
#48 - 2012-04-10 17:40:18 UTC
Bent Barrel wrote:
but that's just mode changing in the dynamic library loader ... a 32bit app cannot load a 64bit library and vice versa, so NO translation is needed. you need a complete 32bit environment for an 32bit application to run on 64 bit OS. Mythas is correct on that part.

No, he is not correct. He believes there is something native about running EVE under Windows opposed to running it under Linux. He is trying to draw a line between the two based on his idea of what makes it native so that he can call one to be native and the other not. Yet he knows that there are many different layers involved between EVE's client code and the operating system. He does this to have an argument and to say that Linux needs a native client. It does not need one and drawing a line in there somewhere is utterly pointless.

If anything then WINE needs to get better. Or the EVE client needs to be written in C/C++ rather than Python.

Loss is meaningful. Therefore is the loss of meaning likewise meaningful. It is the source of all trolling.

Tarn Kugisa
Kugisa Dynamics
#49 - 2012-04-11 05:48:59 UTC
If EVE had a Linux Client, I would drop windows save for the occasional Steam Game

Be polite. Be efficient. Have a plan to troll everyone you meet - KuroVolt

Bent Barrel
#50 - 2012-04-11 10:31:01 UTC
Whitehound wrote:
Bent Barrel wrote:
but that's just mode changing in the dynamic library loader ... a 32bit app cannot load a 64bit library and vice versa, so NO translation is needed. you need a complete 32bit environment for an 32bit application to run on 64 bit OS. Mythas is correct on that part.

No, he is not correct. He believes there is something native about running EVE under Windows opposed to running it under Linux. He is trying to draw a line between the two based on his idea of what makes it native so that he can call one to be native and the other not. Yet he knows that there are many different layers involved between EVE's client code and the operating system. He does this to have an argument and to say that Linux needs a native client. It does not need one and drawing a line in there somewhere is utterly pointless.

If anything then WINE needs to get better. Or the EVE client needs to be written in C/C++ rather than Python.


please note that I was replying to one specific part of the whole discussion. that's whay the quote function is there ....

if you check earlier, I am not a fan of a native client, however I'd like some wine consideration during development ....

as to you c/c++ vs python comment, the programming language has no effect. it's the platform bindings that do (directx being the biggest one).
Whitehound
#51 - 2012-04-11 11:18:34 UTC
Bent Barrel wrote:
please note that I was replying to one specific part of the whole discussion. that's whay the quote function is there ....

if you check earlier, I am not a fan of a native client, however I'd like some wine consideration during development ....

as to you c/c++ vs python comment, the programming language has no effect. it's the platform bindings that do (directx being the biggest one).

The whole point of this discussion is the need for speed. CCP mentioned some time ago that parts of their client are written in C++ and others in Python. They say that it is good enough and only the DirectX stuff which is written in C++ iirc. However, seeing how they improved text rendering recently would a client written entirely in C/C++ (and properly optimized by a compiler) likely give a noticeable speed boost over the current Python based code. When I turn off the UI with CTRL-F9 then my frame rate goes up from 40-50 fp/s to a solid 60 fp/s. This is quite a bump. I am pretty sure that this is because of the Python code doing UI stuff. Only CCP will really know why this is.

Loss is meaningful. Therefore is the loss of meaning likewise meaningful. It is the source of all trolling.

Bent Barrel
#52 - 2012-04-11 14:45:56 UTC
Whitehound wrote:
Bent Barrel wrote:
please note that I was replying to one specific part of the whole discussion. that's whay the quote function is there ....

if you check earlier, I am not a fan of a native client, however I'd like some wine consideration during development ....

as to you c/c++ vs python comment, the programming language has no effect. it's the platform bindings that do (directx being the biggest one).

The whole point of this discussion is the need for speed. CCP mentioned some time ago that parts of their client are written in C++ and others in Python. They say that it is good enough and only the DirectX stuff which is written in C++ iirc. However, seeing how they improved text rendering recently would a client written entirely in C/C++ (and properly optimized by a compiler) likely give a noticeable speed boost over the current Python based code. When I turn off the UI with CTRL-F9 then my frame rate goes up from 40-50 fp/s to a solid 60 fp/s. This is quite a bump. I am pretty sure that this is because of the Python code doing UI stuff. Only CCP will really know why this is.


that is possible ... I noticed the other way around. the more windows I have open (corp, contracts, market etc.) the lower my FPS.

however it does not matter how the client is coded if it depends on windows native services/libraries. even if it was entirely c++, we'd still need wine to run it.
Whitehound
#53 - 2012-04-11 16:30:11 UTC
Bent Barrel wrote:
however it does not matter how the client is coded if it depends on windows native services/libraries. even if it was entirely c++, we'd still need wine to run it.

But what is the point of saying this?! You still will need Windows to run the C++ programs, too. You cannot run them without an operating system. WINE Is Not an Emulator... It is a binary loader and linker just like you have under Windows and Linux. Linux has got an ELF and a.out loader in kernel space. WINE is the same thing only does it run in user space and it loads Windows binaries.

Loss is meaningful. Therefore is the loss of meaning likewise meaningful. It is the source of all trolling.

Bent Barrel
#54 - 2012-04-12 09:42:53 UTC
Whitehound wrote:
Bent Barrel wrote:
however it does not matter how the client is coded if it depends on windows native services/libraries. even if it was entirely c++, we'd still need wine to run it.

But what is the point of saying this?! You still will need Windows to run the C++ programs, too. You cannot run them without an operating system. WINE Is Not an Emulator... It is a binary loader and linker just like you have under Windows and Linux. Linux has got an ELF and a.out loader in kernel space. WINE is the same thing only does it run in user space and it loads Windows binaries.


not using windows native services, you can just recompile and run anywhere ... so porting is much easier ... however dependenacies force you to eithre recode or use crutches like wine.

also wine is NOT only a binary loader and linker, it emulates parts that don't have corresponding functionality in linux (i.e. d3d to ogl translation, threading model etc.).
Arachno Webb
Imperial Shipment
Amarr Empire
#55 - 2012-04-12 22:51:26 UTC
Well they _had_ some kind of Linux client earlier on, and it was also based on WINE if I remember correctly. Let me tell you this: It sucked big time. Very soon everyone was using the Windows version with their own WINE. What we need is not a 'native' version, but for CCP to align some more with WINE to make things more playable. For this they need to:
- Drop DIrectX and start using OpenGL (as they did before if I remember correctly)
- Give some pointers to the WINE development on how they use certain stuff and submit some code to improve it.
- Do some compatibility testing

Perhaps this is a lot to ask, but perhaps not, I can't judge on that. But it also seems not to be an outreageous request from our side to ask for some more thought when it comes to the Linux players.
As a side note: For me, at this moment, EVE on WINE works quite good. It could use a speed bump, but for the most part, this game is very playable. At least, to my standards, which may be altogether too low, but ok ;-)
Bent Barrel
#56 - 2012-04-13 10:09:56 UTC
EVE never used OpenGL, it was a D3D game from the start.
Areale
Blood Talon LLC
#57 - 2012-04-24 23:15:25 UTC  |  Edited by: Areale
Perhaps if we all do as I do we can convince CCP to put some serious weight behind "Official" linux support.

about once a year, I re-up an account and see if I can get it to run in linux. If I can, I renew ALL my accounts and purchase several plex's to sell on a regular basis (about 75 - 100 bucks a month in total).

When they make a release or "Patch" that breaks the client on wine, I cancel my subscriptions and stop buying products from CCP. Ultimately taking money out of their pocket. I make my voice heard by NOT contributing to a company that HAS made the choice to NOT support my operating system.

In the end, this is the ONLY way CCP will consider this seriously. They are a for profit company and unless they start seeing their revenue drop due to a lack of support for a segment of the community, they will continue to ignore us and assume that we are hopelessly hooked on their product and that we are willing to go to almost any length to get our "EVE" fix.

So either take the proverbial needle out or accept the fact that CCP is going to make you their .......... well you get the point.

Areale
Buzzy Warstl
Quantum Flux Foundry
#58 - 2012-04-25 13:11:17 UTC  |  Edited by: Buzzy Warstl
I just picked up a piece of information that I did not have previously:
The Mesa OpenGL library team has been implementing some key D3D functions, which means that with some Python hackery a truly native Linux client may be possible soon.

The distribution requirements would be pretty recent, but it's not like it costs much for people to upgrade, eh?

http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/d3d1x

http://www.mud.co.uk/richard/hcds.htm Richard Bartle: Players who suit MUDs

nosmyrC
Umbrella C0rp
#59 - 2012-04-27 05:46:55 UTC
I would just like to see the devs work a little closer with the wine devs. Then when a problem does arise the wine group could help the CCP devs solve the problem quicler.
Falrec
Dremor Engineering inc.
#60 - 2012-05-02 10:44:44 UTC  |  Edited by: Falrec
Install Eve online thanks to Wine is really difficult for someone with little computer knowledges like me. The return of a linux client would be a good idea. Today, I use windows only to run my games.Oops

(sorry for my bad english Roll )