Announcement

Collapse
No announcement yet.

Proprietary software in Linux

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

  • #31
    Originally posted by Nobu View Post
    Not even sure how I want to respond to this...
    Sorry but that's the sad fact of life in regards to publishers, they want to suck as much money as they can out of you through licensing, thankfully they will be deprecated because of digital distribution.

    Originally posted by Nobu View Post
    Well, if you're downloading the game, then you can download it from within the VM and store it there. If you have a CD, then I suggest you store it however you normally store your CDs. Why would you have to restart in order to run a game?
    This exceeds the scope of a minimalist distro to host a game through (Also take note that you don't have a browser in this distro which you stated as the terms yourself), which is what you and others who push the argument you are are going for. The Idea is usually presented as you basically have live CDs for individual games, which are then run through the VM. If this is not what you're presenting this then what's the point of linux users for instance running this game in a VM?

    Originally posted by Nobu View Post
    I said it would be, I didn't say it was possible yet...though I can't believe nobody has done it yet--is it that hard?
    It should be quite obvious that it is, given nobody has done it yet, and they've been working at it for quite some time.

    Originally posted by Nobu View Post
    It does nothing of the sort; if the CPU supports VT-extensions (most recent processors do), software runs as if it's on an actual CPU...because it is. There is no special API--it just works.
    Um.. yeah it does, and the CPU matters less for gaming than you think (and I wasn't talking about that in the first place), most of the work is being done on the GPU which your VM just put a massive layer between it and the hardware until they can get the other figured out, which is what the developers are wanting to get closer to, or did you fail to read the article?

    Originally posted by Nobu View Post
    What in the world are you talking about? What I proposed has absolutely no affect on what developers choose to use for development and testing.
    No it doesn't, not the developers side but that wasn't what I was talking about. You missed my two points. #1 Proprietary software tends to be half baked and so it NEEDS patches to fix it, particularly at 1.0 versions. #2 People like to hack and mod software to fit their needs, this supports the game and creates a community around it, and is better for everyone. You admitted yourself the VM solution doesn't account for patches or mods which are very important.

    Originally posted by Nobu View Post
    Cool, I wasn't being sarcastic; that was a completely honest question.
    And I answered your question in an honest if forceful manner. I may be harsh, but I'm being so purposefully, as there is already a present solution that merely needs to be taken advantage of, rather than introducing extra overhead into the system.

    Comment


    • #32
      Originally posted by Luke_Wolf View Post
      This exceeds the scope of a minimalist distro to host a game through (Also take note that you don't have a browser in this distro which you stated as the terms yourself), which is what you and others who push the argument you are are going for. The Idea is usually presented as you basically have live CDs for individual games, which are then run through the VM. If this is not what you're presenting this then what's the point of linux users for instance running this game in a VM?
      Right, I forgot that there's no browser. A lightweight browser wouldn't take up much space in the VM, though, especially compared to all the other stuff you could take out of the distribution. I don't expect you to use a separate VM for each game; that would be ridiculous and overkill. One VM is the most you should need; a second would only be necessary if you want to play a very old (5-10+ years) game which was designed for an older, non-binary compatible version of the distribution. The point, as I presented it in my first post (maybe not as clearly as I have here), is to provide game publishers a single distribution to target with a stable platform (no ABI breaks or major package changes in bugfixes or updates, and only a major upgrade every 4-8 years; could be based on Debian, I suppose), and provide users a way to play these games on any distribution via the VM.


      Um.. yeah it does, and the CPU matters less for gaming than you think (and I wasn't talking about that in the first place), most of the work is being done on the GPU which your VM just put a massive layer between it and the hardware until they can get the other figured out, which is what the developers are wanting to get closer to, or did you fail to read the article?
      I read the article. As I've said before, I'd proposed this assuming that eventually we'll have GPU pass-through. You've made your point, though, and I understand that it may be a while until it happens, and until then this solution isn't a solution.

      No it doesn't, not the developers side but that wasn't what I was talking about. You missed my two points. #1 Proprietary software tends to be half baked and so it NEEDS patches to fix it, particularly at 1.0 versions. #2 People like to hack and mod software to fit their needs, this supports the game and creates a community around it, and is better for everyone. You admitted yourself the VM solution doesn't account for patches or mods which are very important.
      You missed a very important statement in my first reply to you: Your solution works on any platform, so why can't it handle updates on there just like it handles updates on any other distribution?

      And I answered your question in an honest if forceful manner. I may be harsh, but I'm being so purposefully, as there is already a present solution that merely needs to be taken advantage of, rather than introducing extra overhead into the system.
      Sure, but when the overhead is gone, we'll all be happy in lunchlady land.
      Last edited by Nobu; 11 August 2011, 11:02 AM.

      Comment


      • #33
        Originally posted by Luke_Wolf View Post
        Um.. Just What? This statement makes absolutely no sense because software works regardless of the desktop you're using. Now if you were arguing that GTK looks terrible under Qt based Environments unless you've got GTK-Qt-engine or otherwise installed then you might have a point, however you appear to be arguing to have one desktop environment, which is just plain silly as as long as you have Qt or GTK (depending upon what the software is using) installed you don't need to worry period.
        For all but simple apps you need to integrate with the Desktop API/SDK. For instance Gnome/KDE each have their own way to save settings, each way to get notifications such as power down, etc. Each have their own way to interact with the email tool or calendar.

        I know all this because I worked for a company that tried to create a KDE app, but gave up as the API just kept changing every 6 months.

        Even if you wrote an app for QT, which version do you write for, 4.7.X, 4.8.X. Then you either pray Ubuntu, RedHat, ship the same version or you ship your own QT. Good luck with that.

        You could go the way of FireFox, Skype, Google Earth where you build static, but then every app has its own look and feel. Not a great experience for the user.

        Comment


        • #34
          Originally posted by DarkCloud View Post
          For all but simple apps you need to integrate with the Desktop API/SDK. For instance Gnome/KDE each have their own way to save settings, each way to get notifications such as power down, etc. Each have their own way to interact with the email tool or calendar.

          I know all this because I worked for a company that tried to create a KDE app, but gave up as the API just kept changing every 6 months.

          Even if you wrote an app for QT, which version do you write for, 4.7.X, 4.8.X. Then you either pray Ubuntu, RedHat, ship the same version or you ship your own QT. Good luck with that.

          You could go the way of FireFox, Skype, Google Earth where you build static, but then every app has its own look and feel. Not a great experience for the user.
          Correct me if I'm wrong (i'm still working on learning Qt), but my understanding was that as long as it's part of a series 3.x, 4.x, 5.x, etc Software based on Qt is Forwards compatible (Ie software that was written and compiled for 4.7.x would work with 4.8.x), and that a change in series number marked an ABI break.

          Comment


          • #35
            Originally posted by Nobu View Post
            Right, I forgot that there's no browser. A lightweight browser wouldn't take up much space in the VM, though, especially compared to all the other stuff you could take out of the distribution. I don't expect you to use a separate VM for each game; that would be ridiculous and overkill. One VM is the most you should need; a second would only be necessary if you want to play a very old (5-10+ years) game which was designed for an older, non-binary compatible version of the distribution. The point, as I presented it in my first post (maybe not as clearly as I have here), is to provide game publishers a single distribution to target with a stable platform (no ABI breaks or major package changes in bugfixes or updates, and only a major upgrade every 4-8 years; could be based on Debian, I suppose), and provide users a way to play these games on any distribution via the VM.
            Fair enough I suppose, although cross platform/open source engines are still a more elegant and flexible solution to the problem.

            Originally posted by Nobu View Post
            I read the article. As I've said before, I'd proposed this assuming that eventually we'll have GPU pass-through. You've made your point, though, and I understand that it may be a while until it happens, and until then this solution isn't a solution.
            Correct, while separation of content and engine will work forever so long as the engine continues to be maintained (which if it's open source means basically forever)

            Originally posted by Nobu View Post
            You missed a very important statement in my first reply to you: Your solution works on any platform, so why can't it handle updates on there just like it handles updates on any other distribution?
            Because what you were proposing wasn't really made properly clear until this post, I was (understandably) under the impression that you were arguing what other people have done in this regard rather than a similar but tangential concept.

            In that case it would work, although once we have the other properly the VM becomes irrelevant, as only the engine needs to be targeting anything, and of course if it's made opensource the problem is solved permanently.

            Originally posted by Nobu View Post
            Sure, but when the overhead is gone, we'll all be happy in lunchlady land.
            perhaps, we shall see what happens in the next few years, I have a feeling that desura is going to be huge for the indie game scene, and with it we'll see the second dawn of gaming based in independent developers rather than in publishers, as outside of the initial investment it's rather hard to argue for having a publisher when you can distribute your software for (basically) free

            Comment


            • #36
              Originally posted by Qaridarium
              the only problem is old software do not support pulse audio.
              Ahh but that library layer was supposed to be one of the HUGE features of pulseaudio.

              Comment

              Working...
              X