Announcement

Collapse
No announcement yet.

Best bang for buck with open source drivers.

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

  • #46
    Originally posted by duby229 View Post
    If you have an API with a function that is used by 20% of the applications that use that API, and later on find out that function can be used to exploit the system for something
    API's can't really have exploits, API *implementations* do. You can still fix the implementation while keeping the API as it was. You don't remove the function, you just make it safe. Your reasoning sounds pretty much like FUD. (let alone that many times the myth that the API gets changed only to fix exploits stays a myth and it seems it in most cases it just gets changed because stuff gets marked unused by main kernel tree modules, then eventually it gets dropped out altogether even though there might have been tons of stuff outside the main kernel tree that used it that simply never got integrated in the kernel tree)
    Last edited by nanonyme; 07-03-2009, 10:06 AM.

    Comment


    • #47
      in the argoment of stable api: http://www.kroah.com/log/linux/stable_api_nonsense.html

      Comment


      • #48
        Originally posted by duby229 View Post
        I'll be completely sure to stay 100% away from any and every closed driver. That'll never happen ever. No offense it's just that since everything else in the linux world is open source, there shouldnt be any exceptions ever. Personally I think that there should be some kind of flag that identifies closed source code and then makes it impossible for it to execute. Something like the NX bit except for use in blocking closed source code. I think the same kind of technology that identifies viral code could be adapted to identify closed code as well...
        There is a flag in the kernel to disable all non-GPL modules.

        Comment


        • #49
          Originally posted by nanonyme View Post
          API's can't really have exploits, API *implementations* do. You can still fix the implementation while keeping the API as it was. You don't remove the function, you just make it safe. Your reasoning sounds pretty much like FUD. (let alone that many times the myth that the API gets changed only to fix exploits stays a myth and it seems it in most cases it just gets changed because stuff gets marked unused by main kernel tree modules, then eventually it gets dropped out altogether even though there might have been tons of stuff outside the main kernel tree that used it that simply never got integrated in the kernel tree)
          I never said that is the only reason broken API's get dropped, but I certainly do believe it is an important one. Now some people call everything they hear that they dont agree with FUD. You may or may not be one of those people, but I cant quite explain why you attempted to call my argument FUD. Was I trying to make you fear what I was saying? Was I trying to make you uncertain of what I was saying? Was I trying to make you doubt what I was saying? See I dont understand how in your mind FUD applies. Why would I purposely make you fear or uncertain of or doubt what I was trying to say?

          EDIT: And about dropping old and crusty API's that dont get used by in the kernel tree, That is a freakin fantastic idea. All I can say is that thank god I dont have a 16GB kernel.......... I hope and pray, yes pray, that Linux never develops its version of winsxs....
          Last edited by duby229; 07-05-2009, 11:44 AM.

          Comment


          • #50
            Originally posted by duby229 View Post
            EDIT: And about dropping old and crusty API's that dont get used by in the kernel tree, That is a freakin fantastic idea. All I can say is that thank god I dont have a 16GB kernel.......... I hope and pray, yes pray, that Linux never develops its version of winsxs....
            Well, yes. Admittebly API has to be allowed to live and old versions of the API have to eventually be droppped. This simply because no sane person manages to predict every use scenario so the attempt for the API will be wrong. This has nothing to do with security holes though. So yes, I admit API has to go through changes (after having doing some conversing Elsewhere (tm)) as part of its natural evolution to better cope with tomorrow's challenges which simply weren't thought of yesterday.
            But yeah, I still stand by my claim that saying actual API changes due to security reasons makes no sense whatsoever. (FUD as in the sense that the reasoning you gave is not only false but it was directed towards the emotional core of every admin: security. It's a bit like drawing child porn card in an arbitrary network filtering conversation, really Drawing them randomly when they're not actually related to the matter at hand is meant to be a conversation killer and an "I Win" card)

            Comment


            • #51
              Originally posted by nanonyme View Post
              Well, yes. Admittebly API has to be allowed to live and old versions of the API have to eventually be droppped. This simply because no sane person manages to predict every use scenario so the attempt for the API will be wrong. This has nothing to do with security holes though. So yes, I admit API has to go through changes (after having doing some conversing Elsewhere (tm)) as part of its natural evolution to better cope with tomorrow's challenges which simply weren't thought of yesterday.
              But yeah, I still stand by my claim that saying actual API changes due to security reasons makes no sense whatsoever. (FUD as in the sense that the reasoning you gave is not only false but it was directed towards the emotional core of every admin: security. It's a bit like drawing child porn card in an arbitrary network filtering conversation, really Drawing them randomly when they're not actually related to the matter at hand is meant to be a conversation killer and an "I Win" card)
              Security absolutely is an important reason to modify existing API's. I'm not saying its the only one, but I am saying that as an admin it is one of the reasons that I can relate to. As such that is the reason I mentioned security in the first place. I fully appreciate that there exists many usage scenarios, unfortunately I catn know all of them and can only relate what I know. In my field security is prime.

              I didnt intend it to be a conversation killer per se, but I did intend to get my point across efficiantly. We've been swapping posts now for too long in my opinion about something that neither one of us is going to change our minds on. For some reason that you still havent justified you think it is a great idea to keep around incomplete, broken, insecure, unstable, flawed, poorly designed API's that have no possibilty of being fixed and will be replaced anyways....Fine.... I'm perfectly ok with that. There actually exists such a thing that does exactly what you want. Its called winsxs.

              Comment


              • #52
                Originally posted by einaudi View Post
                "If Linux had to ensure that it preserve a stable source interface, a new interface would have been created, and the older, broken one would have had to be maintained over time, leading to extra work for the USB developers. Since all Linux USB developers do their work on their own time, asking programmers to do extra work for no gain, for free, is not a possibility." I agree, he makes good points. Might make no sense whatsoever on a free as in gratis operating system. Possibly more so in a commercial opensource operating system.

                Comment


                • #53
                  Originally posted by nanonyme View Post
                  "If Linux had to ensure that it preserve a stable source interface, a new interface would have been created, and the older, broken one would have had to be maintained over time, leading to extra work for the USB developers. Since all Linux USB developers do their work on their own time, asking programmers to do extra work for no gain, for free, is not a possibility." I agree, he makes good points. Might make no sense whatsoever on a free as in gratis operating system. Possibly more so in a commercial opensource operating system.
                  The benefit of this approach, regardless of the reasoning behind it, means that kernel and it's development is a lot more agile. It also in turn encourages in-tree participation, for the benefit of the kernel. Even a commercial open source OS can benefit from this.

                  Comment

                  Working...
                  X