Announcement

Collapse
No announcement yet.

id Software: Linux Hasn't Produced Positive Results

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Kano
    replied
    If they really use the default U 12.04 toolchain then they make a huge mistake.

    Leave a comment:


  • 0xBADCODE
    replied
    Valve's approach just better.

    You see, Valve's approach is simply better.
    • First, they're co-operate with AMD, Intel and Nvidia to improve things rather than just blame them as id guys did. This works far better.
    • Then, Valve runs whole store, not just one game. And should I admit that buying CDs/DVDs is a stone age of computing? So it have to be online downloads. Valve got it right. Well, more or less. There could be some nasty issues like DRM but it's a step forward in better approach, so it's more user friendly. At the end of day it's simply wrong to put extra barriers when I want to buy something.
    • Valve seems to be far more flexible. They got some real Linux gurus, they really did an absolutely asskicking job in optimizing engine. And they did good PR as well, so many Linux ppl are well aware of their activity. Not something that id does well enough.
    • Valve does not releases just one mere game. But a whole bunch of them and engine. Used by dozens of games. And keeps store running. Quite a difference, doh.
    • In fact id seems to be on decline. No, really, they're slow these days and seems to have troubles in keeping up with competitors. Sure, they can't afford much attention to Linux. But it's not Linux people fault.


    So what? Valve seems to perform much better in many areas at the moment. So I guess they can do it better.

    Leave a comment:


  • Kano
    replied
    @gamerk2

    Your point is completely wrong as long as you write apps for the USERSPACE. The userspace did not break, system level tools needed to be adjusted from kernel 2.4 to 2.6 series and some small changes have been needed for the newer 3.x naming scheme. But a standard userspace tool NEVER broke because of those changes. Your Linux API does only matter for kernel drivers - if you are really able to write those then you can follow upstream or best push your drivers into the mainline kernel. Outside tree drivers are always stupid to maintain. I mainly use 3 outside tree drivers: virtualbox (they are usually fast enough to keep up with mainline), nvidia (also pretty fast), fglrx (those devs are too often on holiday so you have to search for patches on your own). The other part that often changes is Xorg, that can break of course only binary 3d drivers. If you don't work for nvidia or amd all you can do is wait till an updated driver is there. nvidia is usually fast enough to adopt xorg changes, i did not read anything about xserver 1.13 and fglrx recently. So what do you have to care when you write binary userspace apps? Well the main point is to use an older libc6 to compile your app/libs against to make it compatible with older distributions. The worst case is compiling your app on the latest Ubuntu with a default toolchain as that usually that does not allow any Debian user to use it (because libc6 is usually older there). It would work however with other distros with the same or newer libc6. But that has nothing to do with the API you talk about.

    Leave a comment:


  • entropy
    replied
    Originally posted by Scali View Post
    It will be interesting to see what will happen with Steam.
    Valve seems all pro-linux so far, but that is probably a combination of naivety and the fact that they are launching a militant anti-Windows 8 campaign.
    Valve being naive?
    You must be joking.

    Considering the excellent staff they got,
    it's way more naive to call them naive.
    They surely know about the risks.

    Leave a comment:


  • Scali
    replied
    Originally posted by gamerk2 View Post
    I'm speaking as a developer. I'm not going to re-design my application two years after I release it because some Linux developer decided to junk a bunch of the API's I used for the latest kernel revision. Its that mindset that's caused Linux to more or less be ignored by the marketplace.

    Linux needs a stable API. Period. Now, feel free to change how that API is implemented as needed, but constantly junking interfaces is the quickest way to get people to ditch development for your OS.
    It will be interesting to see what will happen with Steam.
    Valve seems all pro-linux so far, but that is probably a combination of naivety and the fact that they are launching a militant anti-Windows 8 campaign.
    What will happen if in 1-2 years, games stop working on newer versions of Ubuntu? Games that people paid money for to play...

    Of course, with a bit of luck, the Ubuntu people are smart enough to avoid any software updates that would break Steam games... Then again, that might mean that they get stuck with older versions of Xorg, Qt and whatnot.

    At this point it looks like a house of cards that is going to fall apart horribly in a few years time. I wonder what Valve will say then. Would be great fun to see them backpeddling to Windows 8 (since Windows 7 would no longer be sold by that time). More epic than the end-scroller in Triton's Crystal Dream

    Leave a comment:


  • gamerk2
    replied
    Originally posted by crazycheese View Post
    This is not a "silly" assumption, it is the right thing to do. Regardless of the platform.
    I'm speaking as a developer. I'm not going to re-design my application two years after I release it because some Linux developer decided to junk a bunch of the API's I used for the latest kernel revision. Its that mindset that's caused Linux to more or less be ignored by the marketplace.

    Linux needs a stable API. Period. Now, feel free to change how that API is implemented as needed, but constantly junking interfaces is the quickest way to get people to ditch development for your OS.

    Leave a comment:


  • Scali
    replied
    Originally posted by crazycheese View Post
    No, the right thing to do is to ignore your BS. Easy as that. Gets all problems solved! HF.
    Sounds exactly like Linus Torvalds' attitude...

    Leave a comment:


  • crazycheese
    replied
    Originally posted by Scali View Post
    Just like it is the right thing for users and developers to ignore the platform for exactly such reasons.
    No, the right thing to do is to ignore your BS. Easy as that. Gets all problems solved! HF.

    Leave a comment:


  • Scali
    replied
    Originally posted by crazycheese View Post
    This is not a "silly" assumption, it is the right thing to do. Regardless of the platform.
    Just like it is the right thing for users and developers to ignore the platform for exactly such reasons.

    Leave a comment:


  • crazycheese
    replied
    Originally posted by Kano View Post
    @Scali
    Basically i would say binaries are no huge problem by definition. They are not statically linked but usually a lib dir is provided (or 2 in case of x64/x86 with a switching launcher). When done correctly it works on many distributions out of the box, some games might require symlinks (or just delete the libs) to get newer version. When standard names are used you can simply delete libs, if nonstandard names are used try symlinks. The main targets to do so are libopenal, libsdl or libqt. It is no rocked science to fix those problems. Of couse binaries can be done completely wrong as well, especially when they are build against a new libc6 and the target distro is older. Then you are usually lost. I found some games where "only" the installer had that problem, then i wrote my own install script. Mainly i found those issues by testing games from the Humble bundle, but i did not test those recently (i bought all bundles for the minimum value in order to be able to test when somebody has issues with Kanotix). What can be problematic is that when you use a 64 bit system and your app is 32 bit. Then you need of course 32 bit libs. Depending on your distro it can be easy or more complicated to get em working optimally. So i would like to have got of course 64 bit binaries just because of simpler ways to fix issues. When you look at id games you only got 32 bit binaries so far, this could be done better. But can you tell me which game you bought you could NOT run at all with your favorite Linux distribution? I think those issues could be solved and a vendor could provide a faq with hints for beginners or just a forum where advanced users can help others. Usually there are always ppl out there with more experience and those often help beginners.
    Heh, I don't understand why you care to explain it to him. Look out, the next argument in his hate stack would be "why don't they make stable architecture, x32, x64, multilib, why??11 ".
    Some people search for answers, some people search for a victim to brainfsck.

    Originally posted by gamerk2 View Post
    The failure of thinking here seems to be the (silly) assumption that developers will go out of their way to update their binaries when the linux devs remove some API call that their program uses from the kernel, breaking their program in the process.
    This is not a "silly" assumption, it is the right thing to do. Regardless of the platform.
    Last edited by crazycheese; 15 August 2012, 09:31 AM.

    Leave a comment:

Working...
X