Slashdot Mirror


CCP To Discontinue EVE Online Support For Linux

maotx writes "CCP's recent support for EVE Online in Linux is now set to be discontinued this March. Released last November along with the Mac OS X client, it has failed to share the expected continual growth as seen with Mac client. Feedback on the EVE Online forums, which includes the e-mail in which CCP announced this decision, suggest that the client was not preferred for Linux users as it did not support the Premium graphics client and did not run as well as the win32 client under Wine. For those who wish to stop playing EVE Online, CCP is offering a refund towards unused game time. Select quote from the e-mail: 'The feedback and commitment we obtained from players like you helped both CCP and Transgaming with our attempts to improve on the quality and stability of the client. Many of us in CCP use Linux and are convinced of its merits as an operating system.'"

18 of 299 comments (clear)

  1. Makes you wonder... by Shadow7789 · · Score: 5, Interesting

    why they even released an official client if it performed better under WINE.

    1. Re:Makes you wonder... by vikstar · · Score: 4, Insightful

      makes you wonder how they failed to realease an official client that performs better than under WINE.

      --
      The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.
    2. Re:Makes you wonder... by Jamie's+Nightmare · · Score: 5, Funny

      I don't know. All good questions, but somehow we've got to find a way to blame Microsoft for this.

      --
      "When you see a unixer brainwashed beyond saving, kick him out of the door." - Xah Lee
    3. Re:Makes you wonder... by psetzer · · Score: 5, Funny

      The usual way is implying that Microsoft paid them off to kill the Linux client. Considering the state of the Icelandic economy and the number of people actually using that client, I think that probably amounted to mailing them a really nice fruit basket.

      --
      "Anyone who attempts to generate random numbers by deterministic means is living in a state of sin." -- John von Neumann
    4. Re:Makes you wonder... by shaitand · · Score: 4, Informative

      Wine isn't an emulator. Seriously, wine is a native implementation of the win32 api. Saying that wine is an emulator is like saying mono is a .net emulator, or that glut is an OpenGL emulator. An API isn't code, its a specification. Win32 is a specification not code, Wine is just an implementation of that specification on Linux.

    5. Re:Makes you wonder... by onefriedrice · · Score: 4, Informative

      ... or that glut is an OpenGL emulator.

      Given your other examples, you probably meant mesa in place of glut.

      --
      This author takes full ownership and responsibility for the unpopular opinions outlined above.
  2. Re:Is it really so hard to support Linux natively? by imsabbel · · Score: 4, Insightful

    To your title: Yes.
    Its easily a support nightmare.

    OTOH, i am very sure that CCP looked at their stats, counted the number of linux cusomers and made some quick calculations that showed they will never make the money they would need to spend.

    --
    HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
  3. Re:Bummer for them... by pilot1 · · Score: 4, Informative

    CCP doesn't support Linux, but wine has done a good job of making sure it runs well. I've been playing for a little over 2 years and have never had any problems with wine.

  4. I use Linux heavily by sentientbrendan · · Score: 4, Interesting

    and do all of my development work on it... and periodically I reboot into Windows to play Fallout 3.

    I like Linux for development, but the fact is that it is not as good of a gaming platform as Windows is.

    Windows has better video drivers, and it has a tons of teams at Microsoft working on things like directx that directly support gaming. Aside from that it has an enormous industry devoted to developing windows games.

    Oh, and sound just works on Windows, did I mention that? That's pretty important for games. I have surround sound working on my Linux install, which took some doing, but as soon as I plug in my USB headset so I can use skype, the Linux sound system explodes. That means that even if left for dead was on Linux, I still wouldn't be able to play it.

    Really, I don't see what the big deal with dual booting is and since people like me are just going to dual boot, I can't imagine why any game maker would waste money on a Linux port.

    If I can play my game even marginally better on windows I have no reason not to get the windows version.

  5. Re:Surprisingly hard by coryking · · Score: 5, Insightful

    Yes, but by standardizing API's and kernel goo it would make it easy for so-called proprietary vendors like CCP to support Linux. According to som in the Linux community it is fact better to provide random API's that change all the time--that way proprietary vendors get scared off.

    The fact that Linux is so hard for vendors like CCP is seen by some in the Linux community as a feature, not a bug. Hopefully, those very same people in the community are cheering CCP pulling out of native Linux support, as it clearly shows their plan is working as intended.

  6. Re:Surprisingly hard by Pecisk · · Score: 5, Interesting

    Ohh my God, another "Linux architecture is hard, therefore vendors have problems" apologist.

    Listen, CCP was never hiding behind a fact that so called "Linux client" is just a Windows client with Wine wrapper. And frankly, with Wine or Crossover Games you would have more success than Transgaming (which from mine point of view is completely shite). Transgaming based client has hard time with ATI video cards, with exsotic sound card settings, etc. Of course you can tweak it, but what's the point then? They have nice forum where people already exchanging with ideas how to get EVE running on Linux.

    There are one space sim (rather funny one), which has real *native* client. NEVER had problems with that, even on open source ati drivers on Radeons. So propably it is not that hard to do that...natively.

    --
    user@ubuntubox:~$ stfu This server is going down for shutdown NOW!
  7. Sure thing boss. by coryking · · Score: 4, Interesting

    So, how do we permit plugins while prohibiting proprietary plugins, and how do we do it while staying within the bounds of copyright law which is the basis of the GPL?... ...most people participating in the related discussions on the gcc mailing list, suggested already that an unstable plugin API would bring all major advantages of plugins in gcc, while complicating the scenario of proprietary plugins.

    - GCC Plugin Wiki

    That is the first that comes to mind. I believe Linus himself has been quoted as saying something along the lines of "We don't promise a stable kernel ABI and if that means breaking binary drivers, oh well, in fact we might change the ABI just to break them on purpose!". Can't find the quote though.

    And if you still aren't convinced, just browse the comments right here at Slashdot every time there is a story about some driver somewhere. There indeed exists a group of people who want to purposefully mix shit up hoping to scare certain kinds of developers away.

    1. Re:Sure thing boss. by shutdown+-p+now · · Score: 4, Interesting

      What a find! Wow... just wow:

      A gcc-based scripting interpreter could by default check for a mandatory license statement (header) in every source file, so that "stock gcc" could deny running plugins (scripts) with a non-matching license header/marker telling the user that stock gcc only runs plugin scripts covered by the GPL.

      In addition, SDK users could -by design- be required to explicitly set up each individual plugin to be covered by the GPL, e.g. by making the proper "init" calls at startup, along the lines of setLicense(GPLv2);

      In order to make it harder for non-GPL'ed plugin SDKs to be used with gcc, stock gcc could by default also require each plugin to provide a certain set of hooks that provide licensing information to the host, so that stock gcc may refuse to run such binaries that do not provide the required information.

      Furthermore, it would be possible to require all plugins to be statically linked with the corresponding plugin SDK (making the plugin itself GPL'ed thereby), thus whenever the checksum/hashes of linked in files doesn't match (the ones of the SDK), gcc could refuse to run any such plugins.

      This whole license/checksum/hash verification stuff sounds conspicuously DRM-like to me. But of course it's okay if it's used to force more code under the GPL, right? right?..

  8. Re:I felt a great disturbance in the Force... by rob1980 · · Score: 4, Funny

    ... as if tens of nerds suddenly cried out in terror and were suddenly silenced.

    Fixed. This is Eve Online we're talking about after all, and not World of Warcraft... ;)

  9. migration path by Lord+Ender · · Score: 5, Funny

    CCP is encouraging users of the Linux EVE client to upgrade to the OpenOffice.org Calc application.

    --
    A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
    1. Re:migration path by meist3r · · Score: 5, Funny

      I heard recently someone disbanded one of the largest tables ever inserted into one of those ... amazing stuff.

  10. Re:Epic fail by MooUK · · Score: 4, Informative

    They, uh, did.

    That was why it worked better in Wine. Cedega wasn't anywhere near good enough.

  11. Re:I don't wonder. by Anonymous Coward · · Score: 5, Interesting

    They use D3D because OpenGL is not particularly good to program with. OpenGL 3.0 is not the much-heralded "fix" to the crap specification that it was supposed to be.

    I work better in OpenGL than D3D, but that's my own familiarity with the API rather than the quality. OpenGL has huge gaping problems. A few basic issues...

    -everything's a fucking GLuint, so you have to wrap and cast everything to make it halfway tolerable (at which point it looks so close to D3D that, for the important platforms, you might as well have already done it in D3D)

    -GLSL sucks, with weird and arbitrary rules

    -GLSL shaders can't be compiled (there are ways to do this but they are best described as "skiffy" and less charitably described as "broken")

    -no way to query for GLSL functionality (for example, the noise() function always returns 0 on most cards because almost nobody actually implements it)

    -no coherent SDK-type documentation; crap organization of what documentation exists

    -VBO trashes pointer setup. WHY?

    -developing GLSL on nVidia cards is crap, because it's translated into Cg and doesn't correctly report errors on bad code

    -developing anything generally is crap, because there's no analogue to the D3D caps structures that tell you what work on a given machine.

    -using binding to do everything means you can't make what should be really, really simple assertions about the state of your render pipeline between two draw calls (this is just plain fucking unacceptable!)

    Microsoft may be rah-evil or whatever your nearest GNU zealot wants you to believe, but D3D is a vastly superior API. It's pretty hard to fault developers if they choose to use the better API for targeting their primary platform, if they decide that being cross-platform isn't of interest to them.

    You want more developers, have an API that doesn't suck. It is perhaps a very sad statement that WINE's implementation of D3D is a better gaming API than anything native that's currently available on Linux (yes, it uses OpenGL under the hood, that's fine--OpenGL is a decent binding to the hardware but absolute shit for actually developing stuff).