Announcement

Collapse
No announcement yet.

Linux is not ready for Steam

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

  • This is getting off-topic but eh:

    Definitely. I still remember the pain of installing KDE 3.0 on Mandrake 8.2 with just plain RPM.

    But the ability to recompile the applications to use the newer libraries (or make changes to make them compatible) and the complex and comprehensive package management systems used by most modern Linux distributions and the BSDs go a long to alleviate the pain of dependency hell.

    The closed source operating systems don't have nearly as much flexibility in this regard. This isn't a closed source problem, it's more of a symptom.

    -----

    Though the quick pace of the development of the core libraries is making library issues on Linux more of a problem than they should be. I believe that we should slow the development of the core libraries to yearly schedules, which should make it MUCH easier for closed source development. As an example, upgrading GNOME to a major and often binary incompatible new release every 6 months is madness. There's barely any time for bug fixing. Same with the development of the kernel and X11.

    It would do a lot of good if the distributions synced on a yearly schedule.

    Comment


    • Originally posted by darkphoenix22 View Post
      Though the quick pace of the development of the core libraries is making library issues on Linux more of a problem than they should be. I believe that we should slow the development of the core libraries to yearly schedules, which should make it MUCH easier for closed source development. As an example, upgrading GNOME to a major and often binary incompatible new release every 6 months is madness. There's barely any time for bug fixing. Same with the development of the kernel and X11.

      It would do a lot of good if the distributions synced on a yearly schedule.
      This would solve alot of problems while slowing development. Newer libraries catch bugs because the libraries are immediately put into use, so library development would suffer and quality control would go down.

      I was grinding my teeth writing the last post... there are plenty of Closed Source apps which have "no way out" of the library problem. Three words:

      I. Hate. Oracle.

      There is no really good solution to this without changing the core foundation of how libraries work. Perhaps if libraries had the ability to identify what functionality was present in them with no other information to the main binary this could be solved much more easily.

      Think about it- we could throw away other package management solutions entirely. The application binary would tell the "lib fetcher" what library functions it needed, and the libraries themselves would report this information to the repository or "lib server". Rather than downloading packages of libraries, you'd download individual libraries or source tarballs which provided them and compile those on the fly.

      Application: "I require these library functions." => Lib fetch process
      Libraries: "We provide the following library functions." => Lib server process

      Comment


      • Originally posted by kazetsukai View Post
        This would solve alot of problems while slowing development. Newer libraries catch bugs because the libraries are immediately put into use, so library development would suffer and quality control would go down.
        I think just having year-long development cycles with binary compatible bug fixes releases (ala service packs) would be enough to fix this problem.

        There is no really good solution to this without changing the core foundation of how libraries work. Perhaps if libraries had the ability to identify what functionality was present in them with no other information to the main binary this could be solved much more easily.

        Think about it- we could throw away other package management solutions entirely. The application binary would tell the "lib fetcher" what library functions it needed, and the libraries themselves would report this information to the repository or "lib server". Rather than downloading packages of libraries, you'd download individual libraries or source tarballs which provided them and compile those on the fly.
        So basically, manifest files with multiple versions of libraries sitting in RAM and on the HD. I think this would cause more problems then it would fix, not to mention adding a layer of complexity and making these libraries harder to test.

        I think the package management systems we have currently are fine. We just just need to slow down development to allow for bug fixes and stabilizing.

        Comment


        • The problem is not bug fixing. Minor revisions should only change the "function" of a library but not the "interface" or "contract" (aka design by contract). The main problem is that some libraries break the API on minor revisions. Granted C++ is crap when it gets to libraries. It totally lacks encapsulation. Even adding a single private class member can totally kill the ABI and cause apps to crash.

          Comment


          • I agree. There needs to be a much larger emphasis on binary compatibility in the Linux community. Major API/ABI changes are fine, just make them once a year. :P

            Comment

            Working...
            X