Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 47

Thread: Kernel Developers Say No To Binary Blobs

  1. #21
    Join Date
    Sep 2006
    Location
    PL
    Posts
    912

    Default

    I have the right to spend my money on closed, proprietary hardware and software.
    that essentailly means "i have the right to limit my freedom, and give up some of my rights".

    of course you can use proprietary drivers. it's just that they harm linux development model.

    what do you think would happen if nvidia would try to enforce a certain api on the kernel, threatening that they will not adapt the driver, and the kernel should be fixed instead?

    linux developers would have to choose - agree to nvidia, or ignore them and have them fix their driver; kernel is more important.

    they would definitely do the latter, despite the angered users, left with broken drivers.

    also - bug reports from using a kernel with proprietary driver are usually rejected immediately, because this kernel is referred to as 'tainted' by proprietary software. the problem might exists within the blob, which is not kernel devs responisibility.

  2. #22
    Join Date
    May 2008
    Location
    Parish, NY
    Posts
    159

    Default

    Sorry, Yoshi, but I'm with Linus and the others.

    I thought open source was about choice. I didn't choose this laptop with an ATi graphics card (my college did that for me, another story), but I chose to run Linux on it. And I should be able to choose to run the binary drivers until a distro-shipped open source driver does what I want it to, because I choose not to use git and recompile my graphical backbone every other day.

    GNU is all about freedom and choice. I don't think they should take away my choices, even if said choice limits my own freedom.

  3. #23
    Join Date
    Oct 2007
    Posts
    370

    Default

    Quote Originally Posted by yoshi314 View Post
    ah, but of couse. that's totally irrelevant. but the pc is also a device, isn't it?

    think for a moment about custom open-source firmware for routers (esp linksys wrt54gl series). do you still think it's irrelevant if the firmware remains a blob, or is it better to provide an open firmware, which often provides more features than standard stock blob?

    some modems/tuners/wi-fi cards require firmware, that you have to forcefully extract from windows drivers in order to obtain it.what if that would mean violating the software licence? (actually it might be this way already, as most driver licenses prohibit you from messing with the files).
    i wasnt talking about routers like those..

    Sure, it would be by far best to also have free firmware for every device, what i was saying, is simply, that whether the nonfree binary blob exists in the form of a rom chip on the device itself, or in a blob in userspace, being loaded to the device at driver start, doesent matter to me, and furthermore, i said that there is a HELL of a difference between this, and having a blob like nvidias piece of shit, running inside the kernel.

  4. #24
    Join Date
    Aug 2007
    Posts
    6,641

    Default

    Well binary blobs exist when parts of the code are not under your control. When you look at ID software then you get the idea, they write basically the complete game and do not rely on 3rd party - therefore they could open the code much more easyly than for example Sun for Java - they had to rewrite parts which have been bought. I don't think that you can release the full kernel module code for a driver when it is derived of 3rd party code which has been only licenced - but without the permission to distribute the code. Therefore you see now a complete rewrite as this does not conflict with other copyrights. It seems only Intel did the same as ID for games and has the full source under its control.

  5. #25
    Join Date
    Dec 2007
    Posts
    677

    Default

    Quote Originally Posted by stan View Post
    The hubris!

    If distros like Ubuntu/OpenSuse/Fedora had backbone, they'd plaster warnings to users with NVIDIA hardware urging them to boycott this unscrupulous company. Educating Linux users to spend money to FOSS-friendly manufacturers like AMD/ATI is the only way to make a meaningful statement and vote with their wallet.
    Ubuntu does give the annoying warning actually.

  6. #26
    Join Date
    Nov 2007
    Location
    Die trolls, die!
    Posts
    525

    Unhappy

    Kernel Developers Say No To Binary Blobs
    And nvidia says no to open drivers again?

  7. #27
    Join Date
    Sep 2006
    Posts
    353

    Default

    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.
    Last edited by Jade; 06-24-2008 at 09:40 AM.

  8. #28
    Join Date
    Dec 2007
    Location
    Germany
    Posts
    365

    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.
    Whenever I read your comments I ask myself wether you actually believe what you say or just write it because you're "The Conspiracist"

    EDIT: oh wait, I actually read what you wrote this time and completely agree with you.
    The first time I read I stopped when I came to the "Reiser4" thing, because I thought you'd just talk the usual stuff about that ;-)
    Last edited by NeoBrain; 06-24-2008 at 09:56 AM.

  9. #29
    Join Date
    Apr 2007
    Posts
    44

    Default

    Quote Originally Posted by yoshi314 View Post
    that essentailly means "i have the right to limit my freedom, and give up some of my rights".
    Yes, that's exactly what I'm saying.

    Quote Originally Posted by yoshi314 View Post
    of course you can use proprietary drivers. it's just that they harm linux development model.

    what do you think would happen if nvidia would try to enforce a certain api on the kernel, threatening that they will not adapt the driver, and the kernel should be fixed instead?

    linux developers would have to choose - agree to nvidia, or ignore them and have them fix their driver; kernel is more important.

    they would definitely do the latter, despite the angered users, left with broken drivers.
    No argument from me. In such a scenario, the kernel devs should tell the offending party to go to hell. Nevertheless, you've provided nothing more than a weak hypothetical scenario. If based upon such insubstantial hypothesis, then the kernel devs' symbolic gestures accomplish nothing more than to create an atmosphere of ill-will and uncertainty.

    Quote Originally Posted by yoshi314 View Post
    also - bug reports from using a kernel with proprietary driver are usually rejected immediately, because this kernel is referred to as 'tainted' by proprietary software. the problem might exists within the blob, which is not kernel devs responisibility.
    I find that to be extremely short sighted and arbitrary, but that's their choice. I'm not going to tell them how to do their work.

  10. #30
    Join Date
    Jan 2008
    Posts
    112

    Default

    Quote Originally Posted by NVIDIA via ZDnet
    “NVIDIA doesn’t expect Linux kernel developers to debug issues in NVIDIA’s kernel module.”
    Gotta love the obvious misinformation NVIDIA spews. The kernel developers are not compaining because they can't debug Nvidia's driver. They are complaining because anyone who files a bug report who has also tainted their kernel with Nvidia's (or ATI's) blob, is basically S.O.L. when it comes to getting any kind of assistance for their problem. Having tainted kernels on every desktop keeps kernel developers from properly debugging the Linux kernel.

    Those of you who just love their blobs are welcome to keep them, and the unending, never-fixed bugs that go with them. I for one am longing for the day when I can actually use the features my video hardware came with, without being stuck with a bugfest of a closed driver.

    Quote Originally Posted by immudium View Post
    I find that to be extremely short sighted and arbitrary, but that's their choice. I'm not going to tell them how to do their work.
    It's not a matter short sightedness, I believe it's more a matter of no-sightedness. With the blob loaded into the kernel, NODBOY BUT NVIDIA(or whoever's blob it is) can say what it's doing. That's just the way it goes if you want to load a binary-only module into your otherwise-open kernel.
    Last edited by oblivious_maximus; 06-24-2008 at 02:30 PM.

Posting Permissions

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