X.Org ATI Driver Developer
Would they do anything about it even if the ucode was open? I can guarantee any gfx bug the user is having is not ucode related. Are they not planning to support any x86 CPUs? Those get updated ucode as well.Originally Posted by mbit
Phoronix Member
That likely depends on the license of the ucode. If it was open there could possibly be the option of making a replacement.
Quick question (and pardon my ignorance if this has been answered before) - Why do the Nouveau devs have a FOSS replacement for the Nvidia ucode and the AMD side do not? Is it hard to write a replacement?
X.Org ATI Driver Developer
What would be the advantage of a replacement? First I doubt anyone would write a replacement, but even if someone did, then that's one more potential source of bugs. If there's a bug, it might be a bug in the driver or a bug in the replacement ucode.
Senior Member
Luckily, you remove another source of bugs: the original ucode. So the net result is 0.
Senior Member
I think the question in my mind is why doesn't AMD free the current ucode? Is it because it's tied into the digital restrictions management, or is it a trade secret type of thing?
I understand where Debian is going, and support their ideals. I mean, given a choice, how many of us wouldn't prefer a distribution without binary blobs? A few of the big wifi guys have started to release code recently, and it just might be due to the reality of situations like this.
Video cards are the only exception, because there is no practical fully free substitute. I think if we remove them from the argument, Debian's decision isn't so radical.
Senior Member
Well, that's Debian dudes!
Personally, I think this "all FOSS" philosophy is as radical as using a computer only with MAC OS X or Windows 7 with only proprietary software, and that's not good for the progress of a distro / Linux development. OC, what I'm saying is just a personal opinion...
Cheers!
Phoronix Member
Blobs are crap. Necessary crap, yes, but still crap. Black boxes. The decision to remove them from the kernel is a good one, especially since you all it takes is one step to install them if needed.
I do not see what all the fuss is about.
Debian is what it is.
Junior Member
Something I read somewhere, it made me laughthough for me, i will probably be using binary blobs until the fsf opens a hardware store.
Senior Member
I'll give you an example why this is a bad policy:
Suppose you're a owner of a laptop with a broadcom wireless card or a intel "iwifi" wireless family card (most of the wireless cards you get in modern laptops).
Without these "proprietary blobs", you simply can't use the wireless card of your laptop. For instance, in my Toshiba laptop (a 4-year old A200), the only firmware it'd build as FOSS, would be the 'radeon' one.
So, (for instance), if I tried to use next debian version, by default, I couldn't use my wireless card in the laptop, so it'd be almost unusuable.
But ok, these are interesting news: Now, debian is turning into a GnewSense or Blag thing...
Cheers
Senior Member
I'm an advocate of software freedom, and I think that we need to make difficult choices in order to keep non-free inroads from becoming a slippery slope, as they often do, leading to more and more of the system becoming non-free.
That said, I'm not sure what this move by Debian does to advance software freedom. Unless we are actively working on free software ucode replacements for the hardware whose firmware is culled, this doesn't help us at all.
Imagine a time 10 years from now when hardware manufacturers have wisened up, and allocate a gigabyte or more of flash memory on their video cards to support larger, more all-inclusive firmware. Imagine that "free software" device drivers like `radeong' would then devolve into an exercise of calling into the firmware for high-level tasks. If Linus' policy on non-free firmware were to remain unchallenged by then, we would find ourselves with a free "glue" driver in the mainline kernel, along with a non-free firmware blob implementing the vast majority of the functionality. Is this what you guys want? Because I guarantee you that hardware manufacturers are going to try this tactic sooner or later, because they know that people by and large accept the fact that firmware is non-free, so they can just stuff all their "IP" in there. And as the "IP"-protected subject matter balloons outward indefinitely, soon you find that practically the entire driver is a "firmware" blob.
Critics speak of the GPL being like a virus or a cancer, but so is proprietary software. Debian is severing a limb in order to save the body, but at the same time, this largely nullifies the purpose of the operating system for those desiring to use the hardware that just got "cut"; and these are extremely important pieces of hardware, too. So to finish off the amputee analogy, it seems that Debian (and the free world in general) needs to develop an artificial limb to take the place of the hand that necessarily has to be cut off. We lose in the short term, but win in the long term.
That's the idea, anyway. But right now I see no one actively working on a replacement, so we're just going to live without a hand? Or really, due to the importance of the wifi and video chipsets that just stopped working on Debian, it's more analogous to losing one eye, both hands and both legs up to the calf. The other eye represents the functionality of a Debian system on (for example) an r600 system with Intel wifi: a non-networked X session running vesa. Unacceptable. We have a long road ahead if we want to preserve software freedom.
Reply With Quote
