Announcement

Collapse
No announcement yet.

Ryan Gordon Criticizes Open-Source Drivers Again

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

  • #51
    True, but it is being checked by people other than the manufacturer, which is already a factor that makes it safer.

    Nothing is 100% safe, however.

    Comment


    • #52
      Originally posted by ean5533 View Post
      Good reading. All points that seem obvious after you're read them.

      If one takes everything you've said at face value, the sad conclusion is that the divided world of Linux is fundamentally hostile to 3rd party vendors, and will remain hostile as long as it remains divided. That's quite a depressing realization to have.
      Actually, not really. See, the two alternatives I posited - ship the thing as a static build in a tarball, or let distributors integrate for you - are both actually perfectly workable solutions. There's nothing terribly wrong with either. There's just this odd perception that it should be possible for third parties to ship a single dynamically-linked native package for all distros, otherwise there's a Big Problem. It's simply not true. There's nothing horrible about third parties shipping a statically-linked tarball. It does the job. That's what Firefox nightlies are. It's how most Linux games are distributed, and they work.

      Sure, it's not as neat and efficient as a properly interdependent set of dynamically linked packages - i.e. a distribution. If that's what you want, get distributors to do the integration work. It's what distributors _do_. It simply doesn't actually make sense at all for third parties to be doing this kind of integration work. They don't do it on other operating systems, either, BTW. Windows and OS X apps are far more static than Linux distribution packages. It's the norm for those OSes. There's no particular reason for it not to be the norm for third-party distribution on Linux too.

      (When Windows apps _are_ dynamically linked, btw, the problem emerges there too. How many times have you seen the issue where you have to install some version of DirectX, Visual Basic or .NET shared components that an app is expecting to be there but which actually aren't there in your particular Windows installation?)

      Comment


      • #53
        Originally posted by del_diablo View Post
        Lets separate this into 2 problems:
        1. Actual breakage due libary upgrade
        2. Unsane dependancy managment dening a working package from being installed
        The first requirement to a new package system would be to force the package manager to not be able to block packages or minor version differences. Package needs libGUI2.0.1 and max version is set to version 2.0.2, and my system ships 2.0.03? Frankly, then install the lib and stop complaining!
        I have seen this a few times, and the lack of a "ignore the issue and install anyhow" button annoyed me each time.
        Now, if there is some actual lib differences that cause breakage, the package managers job is to find them, and not "a bit different versions". And if it actually happens, then we suddenly got a valid bug report out of nowhere, instead of the package manager denying installation because it can.
        Ignore the issue and install anyhow is almost exactly never what you actually want, and will cause all sorts of breakage later. The intricacies of interdependent apps and libraries aren't terribly apparent at first, but distributors usually do actually know what the hell they're doing, and if something conflicts or doesn't satisfy a dependency, that's usually _correct_, it's not the distributor being obnoxious just for the hell of it.

        It's pretty hard to provide a condensed explanation of why. It's something you either take on trust or learn through bitter experience. Feel free to choose either path. =)

        Comment


        • #54
          Originally posted by AdamW View Post
          Actually, not really. See, the two alternatives I posited - ship the thing as a static build in a tarball...
          You sound like the most knowledgeable guy in this thread, so hopefully you can contradict a point I've made several times in this thread (a point that hopefully I'm wrong about). If you're shipping a statically linked tarball, how do you know what to link in? The example I've used a couple times is cairo. If I statically link libcairo in my app, I also have to statically link its dependencies or just make the assumption that its dependencies already exist on the user's system(or some combination thereof). There's no standard set of base libraries that I'm guaranteed to have on all Linux distros, so unless I'm missing something then the conclusion is that I'd have to statically link every dependency that chains up from libcairo, which is insane.

          However, you're confident in your answer and you seem more knowledgeable about the subject than me. So what am I missing here?

          Comment


          • #55
            Originally posted by ean5533 View Post
            You sound like the most knowledgeable guy in this thread, so hopefully you can contradict a point I've made several times in this thread (a point that hopefully I'm wrong about). If you're shipping a statically linked tarball, how do you know what to link in? The example I've used a couple times is cairo. If I statically link libcairo in my app, I also have to statically link its dependencies or just make the assumption that its dependencies already exist on the user's system(or some combination thereof). There's no standard set of base libraries that I'm guaranteed to have on all Linux distros, so unless I'm missing something then the conclusion is that I'd have to statically link every dependency that chains up from libcairo, which is insane.

            However, you're confident in your answer and you seem more knowledgeable about the subject than me. So what am I missing here?
            Nothing. You're right. We tend to simplify into 'dynamically linked' and 'statically linked' code, but of course it's not entirely straightforward, as you say: you have to picture the whole stack, from the almost universal, very-slowly-changing stuff down at the bottom (libc) to the stuff at the top which changes ABI every weekend just to stop anyone getting bored (cairo) and pick a cut-off line; you link statically against the stuff above it and dynamically against the stuff below it.

            When we talk about 'statically linked' apps we're referring, in shorthand, to things which draw the line very low, usually more or less right above glibc. It's simply a judgement call you make as a dev. If you want your app to work across all (or at least most) distros you do have to draw it pretty low. LSB stuff is a workable baseline; I wouldn't go much higher. So, yeah, common 'statically linked' apps have a huge pile of stuff linked in. Firefox nightlies certainly do.

            You can mitigate this to some extent by using libraries like SDL which don't depend on a whole lot of stuff beneath them; if you write a game using SDL then statically link in SDL and depend on libc, it's kinda workable.

            (edit: as a disclaimer, I am also good at appearing slightly more authoritative and knowledgeable than I am. I do pretty much know what I'm talking about here, but I could probably nominate quite a few other people - especially at Red Hat - who I'd defer to...)
            Last edited by AdamW; 08 August 2011, 04:23 PM.

            Comment


            • #56
              Originally posted by del_diablo View Post
              2. Unsane dependancy managment dening a working package from being installed
              The first requirement to a new package system would be to force the package manager to not be able to block packages or minor version differences. Package needs libGUI2.0.1 and max version is set to version 2.0.2, and my system ships 2.0.03? Frankly, then install the lib and stop complaining!
              I have seen this a few times, and the lack of a "ignore the issue and install anyhow" button annoyed me each time.
              This "button" (wel, switch) exists in the commandline versions of the package manager, if you really want it, but as explained before making it the default/easy-to-use results into masking of packaging bugs and other bad things.

              Comment


              • #57
                Originally posted by ean5533 View Post
                Hypothetical analogy: It's like a website developer whose sites used to work "everywhere", but suddenly he starts getting reports about his site not working on Opera* because now Opera has enough market share to be considered a major browser. Before Opera became "major", the developer could have just told Opera users to bring their sob stories somewhere else; now suddenly he has to support yet another environment.

                *Note to Opera users: It's a hypothetical situation. Quell your hipster rage.
                This amused me somewhat. I'm a web-developer and I actually develop/test using Opera first then fix the quirks in IE6-7, Safari and Chrome later (Firefox tends to be OK). OK, Opera has its quirks too but they tend to be when using new features of CSS3. Chrome and Safari seem to have issues with JavaScript and images or z-index most often.

                I guess it's like anything; as something starts to be used more widely its quirks become known and you have to find ways to work round them. That happens to be my experience with software, especially IE and Linux, in general.

                Comment


                • #58
                  I just want to +1 those who advocate static linking of closed-source programs. If you are going to distribute a package that cannot be freely relinked to new versions of the dependent libraries, you should offer a static tarball (preferably with dynamic fallback if a .so doesn't exist).

                  One of the great things about Linux is that most of the system is free and open so it can interoperate well, builds can be completely dynamic since it's simple to build against different library versions, etc. I really think this is great for the vast majority of software.

                  However, if you aren't going to participate in that system, there is nothing wrong with a statically-linked package. The users already know that your software is out-of-band because they had to use an unconventional installation method. It should be expected that it would include a bunch of its own crap necessary to make it run reasonably across distributions -- the only reason our apps generally have the freedom to be dynamically linked is because their source is available, they can be recompiled at will, and distros can add hacks as necessary to make the app work as expected against new versions of the library. When we get an app that doesn't have these properties, we can't reasonably expect it to dynamically link everything -- doing so just creates an abundance of cruft for a user to install into his ordinary system paths, and simply *does not work*. It does not produce workable packages.

                  Comment


                  • #59
                    There's another option used by many games that's a good compromise. Bundling the needed dynamic libraries like SDL, OpenAL and whatever. This allows the distributions to use their own builds if they prefer to. This is especially relevant on Gentoo where users build using their choice of optimisations and USE flags. For example, my libSDL is built with the PulseAudio driver. Vendors may prefer to target ALSA for compatibility. If you link the binary in the right way, you shouldn't even need a wrapper script to set LD_LIBRARY_PATH.

                    Off the top of my head, this approach was used by Penumbra: Overture, Aquaria, UT99 and probably many others I can't remember right now. In the case of UT99, we have obviously become more reliant on the bundled libraries over time because it just isn't feasible to package those old versions anymore but that's okay.

                    Comment


                    • #60
                      Originally posted by pingufunkybeat View Post
                      True, but it is being checked by people other than the manufacturer, which is already a factor that makes it safer.

                      Nothing is 100% safe, however.
                      You HOPE it is being checked by other QUALIFIED people. This however has not always been the case. You throw a hello world app in front of almost every one out there and they couldn't tell you if even the syntax is right let alone if it would compromise security.

                      Comment

                      Working...
                      X