Page 5 of 5 FirstFirst ... 345
Results 41 to 47 of 47

Thread: Kernel Developers Say No To Binary Blobs

  1. #41
    Join Date
    Jan 2008
    Posts
    112

    Default

    just thought I'd post a link to this blog post by KDE developer Sebastian Kuegler entitled "How NVidia impedes Free Desktop adoption." He some good points imho: http://vizzzion.org/?blogentry=819

  2. #42

    Default

    Quote Originally Posted by Ex-Cyber View Post
    If someone managed to clone an nVidia GPU (which seems unlikely; the handful of foundries that could manufacture them almost certainly have better things to do), the nVidia drivers would work as-is. If they used some other GPU design as a basis for a counterfeit "nVidia" GPU, they would need a driver for that other design. What use would they have for an open-source nVidia driver?
    I think his argument is, if nVidia open source its driver, then others would be able to clone a nVidia card.

  3. #43

    Default

    Quote Originally Posted by Vadi View Post
    Easier adaption of the driver for that design?

    The only "pro" argument for an open-source driver is that bugs would be fixed. But is this that much of an advantage? Will all bugs be fixed? As real-world examples show, no, oss software can be just as buggy (see ff3 javascript, my personal annoyance). Can the intellectual property be stolen / used for own commercial purposes? Sure. I guess nvidia just don't see the scale tipping into the open-source side all that much.

    Which personally isn't a bother; I'm glad that as a consumer I got a piece of the nice drivers they made for the movie industry
    I think the major problem with close source driver is support.

    There is always a potential problem whenever there are changes to kernel - these close source driver would usually fail to work with newer kernel. It would take them awhile to catch up with kernel's development, at best. In worst case situation, it may take them months to come out a proper driver.

    Though, honestly, nVidia seems to follow kernel development quite nicely, so far.

  4. #44
    Join Date
    Mar 2007
    Location
    MN, United States
    Posts
    285

    Default

    Quote Originally Posted by Jade View Post
    Just a point:

    You say binary blobs should not be in the kernel,... and they aren't,...

    NOT A SINGLE ONE OF THEM.

    They are no more in the kernel than Reiser4.

    So you want binary blobs out of the kernel. Great. They are not in the kernel.

    However, you have to be crazy (or motivated by some other devious factors) to demand that NO binary blobs should ever be able to interact with the kernel.

    This just results in Linux being a poor sad undesirable product, that won't work with heaps of hardware.

    Only those who want to destroy Linux will push hard for this.

    If a hardware maker refuses to open up the specs to his hardware, but offers to provide binary blobs for each kernel, then why would you say no to this offer.

    Of course, it is better to have the specs and write your own drivers, but no hardware maker is compelled to give them to you.

    I suspect the motives of those who demand that NO binary blobs should ever come in contact with the kernel.
    Wow, hey Jade you actually made some sense here, good job man.. Good job.. Haha. Agreed.

    But anyway, my stance on the issue is kinda in the middle. I could really go either way but before I say anything else I do not think now or in the near future is the time to say no to binary blobs. The next few years are going to be quite crucial to Linux's growth as a operating system. Taking away binary blobs now or within a year from now would basically halt this growth.

    One reason for the growth is because of gaming, not just a alternative choice for a operating system but because it can do so much. Take away binary blobs now and you can kiss pretty much any decent retail game bye bye for a while if not forever. That would be a very sad day in my opinion, because everything else outside of games would follow suit possibly.

    The best time to say no to blobs would be when Linux has a good hold on market share as a whole, not just servers, but desktop as well. When its number 1 and nothing can take it down no matter what, thats when you say no to blobs, because then manufacturers will be forced to open their driver or go bankrupt.

    I mean come on, at least bait them first. If not Linux would be shooting its own foot. I think morally its a good move to do, but its just not the right time.
    Last edited by Malikith; 06-26-2008 at 04:30 AM.

  5. #45
    Join Date
    Jan 2008
    Posts
    772

    Default

    Quote Originally Posted by Vadi View Post
    Easier adaption of the driver for that design?
    I don't see how it would help, because in that case the GPU being produced would not be an nVidia GPU, just marketed as one to people who don't know any better.

    The only "pro" argument for an open-source driver is that bugs would be fixed.
    This is far from the only argument. An open-source driver can be maintained in-tree, which means that it will generally do a better job of evolving together with the rest of the infrastructure. Open-source drivers also typically support more host architectures than closed ones. Perhaps most importantly, a proper (non-obfuscated) open source driver is not controlled solely by one vendor; if the vendor has to close its doors, or simply has a management shakeup and decides that supporting Linux is a waste of time, it's still possible for someone to maintain the open-source driver.

  6. #46
    Join Date
    Sep 2006
    Posts
    353

    Default

    Quote Originally Posted by Malikith View Post
    Wow, hey Jade you actually made some sense here, good job man.. Good job.. Haha. Agreed.
    Come on Malikith, I always make sense,....

  7. #47
    Join Date
    Sep 2006
    Posts
    353

    Default

    Any other views on binary blobs in the kernel?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •