Originally posted by Qaridarium
Announcement
Collapse
No announcement yet.
NVIDIA Tries To Put Fence Sync Into X Server 1.10
Collapse
X
-
Originally posted by deanjo View PostNo, a "better way" is to work together regardless of personal opinion, politics, and ideologies for the greater good of the end user whom more then likely don't care about how it is done but the end result is providing a product that does what the end user wants it to do.
Why should either category bend over to accept and *maintain* code for the benefit of a closed-source company that doesn't help in Linux development (e.g. Nvidia)?
Comment
-
Originally posted by BlackStar View PostYou are confused. The end users of the kernel are its own developers, paid or unpaid. The paid ones work on the kernel for the benefit of their company. The unpaid ones work on it as a hobby.
Why should either category bend over to accept and *maintain* code for the benefit of a closed-source company that doesn't help in Linux development (e.g. Nvidia)?
Comment
-
Originally posted by deanjo View PostI'm not confused. There are a hell of a lot more end users that are not devs then there are devs. Whether you like to admit it or not, nvidia does help out in linux development. In fact I would go so far as to venture that without nvidias solutions being available you would not have seen so much progress being made on the linux desktop over the last 8 years simply for the fact of them offering a full featured working solution. Then there is also items such as nvidia's contribution to the open API's such as openGL, openCL, etc. To say that nvidia doesn't contribute to development is BS, it may not offer open documentation to it's products but to say that it doesn't contribute to open projects isn't the truth at all.
I said that Nvidia does not contribute to Linux (i.e. kernel) development. With that in mind, why should kernel developers be tasked with maintaining Nvidia's blob? What would e.g. Red Hat gain from that? Or independent contributors?
Like it or not, the kernel is not developed for you and me. It's developed by Red Hat, AMD, Intel, etc *for* Red Hat, AMD, Intel, etc. The fact that we can use this kernel on our desktop is awesome, but we are certainly not the primary target.
Comment
-
Originally posted by BlackStar View PostWith that in mind, why should kernel developers be tasked with maintaining Nvidia's blob? What would e.g. Red Hat gain from that? Or independent contributors?
Comment
-
-
Originally posted by BlackStar View PostStrawmen and more strawmen.
I said that Nvidia does not contribute to Linux (i.e. kernel) development. With that in mind, why should kernel developers be tasked with maintaining Nvidia's blob? What would e.g. Red Hat gain from that? Or independent contributors?
Like it or not, the kernel is not developed for you and me. It's developed by Red Hat, AMD, Intel, etc *for* Red Hat, AMD, Intel, etc. The fact that we can use this kernel on our desktop is awesome, but we are certainly not the primary target.
If this can be done in opensolaris (and others), i dont know what are we waiting for..
these driver issues and stupid wars can get pretty tiresome. I just want my hardware to work. Do what ever i dont care and get it working.
Comment
-
The kernel doesn't stand by itself. If the kernel only cared about working with the kernel there would be no external interfaces at all. APIs and ABIs exist so that code OUTSIDE the kernel can use it. Kernel developers DO maintain stuff for code that isn't their own. It would be useless if it didn't. They provide facility for code that doesn't live in the kernel and they do it ALL THE TIME.
I regularly change my kernel without recompiling or reimplementing every other binary on my system. I can do that because stable APIs and ABIs exist. I can do that because the kernel guys DO care that software outside their tree and influence works.
People should just be honest and call the issues surrounding BLOB drivers inter-working with the kernel what they are: Pissing matches of political, philosophical, and religious origin. The technical issues are dwarfed more by egos than by difficulty of implementation and maintenance. Making out like the the latter two are some how significant when the former is so much more forbidding is a bit silly.
Comment
Comment