Linked by Thom Holwerda on Fri 14th Sep 2012 22:30 UTC
Intel You'd think this sort of stuff belonged to the past - but no. Apparently, Microsoft is afraid of Android on its Windows 8 tablets, because Intel has just announced that it will provide no support for Linux on its clover Trail processors. Supposedly, this chip is "designed for Windows 8". What?
Thread beginning with comment 535298
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Comment by jigzat
by lemur2 on Sun 16th Sep 2012 07:37 UTC in reply to "RE[4]: Comment by jigzat"
lemur2
Member since:
2007-02-17

My point is that GNUL has always have a harsh relationship with some hardware vendors while Microsoft and Apple have a symmetric relationship with them, they get hardware ahead of everybody else, they even demand features and get specially optimized compilers while GNUL (developers) has to HACK the hardware and do reverse engineer to find out things that big vendors like Apple and Microsoft already know.


In actual fact, there is less and less hardware these days which Linux kernel programmers have to reverse engineer.

Some companies, such as Intel, write open source drivers for Linux for their hardware.

http://www.intel.com/cd/corporate/icsc/apac/eng/teams/331393.htm
http://intellinuxgraphics.org/
http://software.intel.com/sites/oss/

http://www.omgubuntu.co.uk/2010/09/broadcom-releasing-fully-open-so...
http://www.zdnet.com/blog/open-source/broadcom-yes-broadcom-joins-t...
http://www.zdnet.com/blog/open-source/behind-the-open-source-turnar...

Some companies, such as AMD/ATI, provide programming specifications so that open source developers can write drivers for Linux:
http://www.x.org/docs/AMD/
http://www.x.org/wiki/RadeonFeature
http://www.linuxdriverproject.org/mediawiki/index.php/Main_Page#Abo...

"We are a group of Linux kernel developers (over 400 strong) that develop and maintain Linux kernel drivers. We work with the manufacturers of the specific device to specify, develop, submit to the main kernel, and maintain the kernel drivers. We are willing and able to sign NDAs with companies if they wish to keep their specifications closed, as long as we are able to create a proper GPLv2 compliant Linux kernel driver as an end result."

Some companies only go half-way to true GPL-copyleft open source, but developers can still write drivers for Linux:
http://www.malideveloper.com/developer-resources/drivers/open-sourc...

Linux drivers where the developers have to reverse-engineer hardware do still exist:
http://nouveau.freedesktop.org/wiki/FeatureMatrix
... but such drivers are most decidedly in the minority these days. It is a relatively simple matter to avoid hardware, such as nvidia graphics, which still require reverse-engineered drivers.

Edited 2012-09-16 07:55 UTC

Reply Parent Score: 3

RE[6]: Comment by jigzat
by ilovebeer on Sun 16th Sep 2012 15:20 in reply to "RE[5]: Comment by jigzat"
ilovebeer Member since:
2011-08-08

It is a relatively simple matter to avoid hardware, such as nvidia graphics, which still require reverse-engineered drivers.

Using Nvidia graphics cards in linux does NOT require reverse-engineered drivers. Nvidia provides 32 & 64 bit linux drivers, and communicates well with users to resolve bugs and add features/support.

Reply Parent Score: 4

RE[7]: Comment by jigzat
by lemur2 on Mon 17th Sep 2012 07:47 in reply to "RE[6]: Comment by jigzat"
lemur2 Member since:
2007-02-17

"It is a relatively simple matter to avoid hardware, such as nvidia graphics, which still require reverse-engineered drivers.

Using Nvidia graphics cards in linux does NOT require reverse-engineered drivers. Nvidia provides 32 & 64 bit linux drivers, and communicates well with users to resolve bugs and add features/support.
"

If one uses the binary blob driver provided by nvidia, one cannot upgrade to Wayland in the near future.

Nvidia's binary blob driver is NOT shipped with Linux distributions, one has to download it separately and actually compile a piece of wrapper code. Any issues the driver causes cannot be addressed by the Linux kernel developers. This is most decidedly NOT recommended for non-expert users.

Every time one updates the kernel, one has to recompile the open source wrapper which sits between the binary blob and the kernel. This requires that one has Linux kernel source code installed. It is an utter pain.

For this and other reasons, it is not recommended to use the nvidia binary blob driver. Since the open source nouveau driver is limited due to the need to reverse engineer, that driver although better does not deliver anywhere near the capabilities of the card.

Since it is a is a relatively simple matter to avoid nvidia graphics and use instead a graphics card which does have a functional, well-performed open source driver which ships as part of the Linux kernel itself, (i.e. Intel or AMD/ATI graphics), then using such hardware for desktop Linux systems is overwhelmingly to be recommended.

Edited 2012-09-17 07:48 UTC

Reply Parent Score: 2

RE[6]: Comment by jigzat
by Neolander on Mon 17th Sep 2012 09:28 in reply to "RE[5]: Comment by jigzat"
Neolander Member since:
2010-03-08

"We are a group of Linux kernel developers (over 400 strong) that develop and maintain Linux kernel drivers. We work with the manufacturers of the specific device to specify, develop, submit to the main kernel, and maintain the kernel drivers. We are willing and able to sign NDAs with companies if they wish to keep their specifications closed, as long as we are able to create a proper GPLv2 compliant Linux kernel driver as an end result."

Wow. Just, wow.

"We Linux devs have finally managed to go far enough in market share that hardware vendors will care about us. Now that we are here, we don't care for the younger OSs that are struggling just like we did before anymore, and will gladly sign NDAs on specs so as to keep an edge on them"

Edited 2012-09-17 09:37 UTC

Reply Parent Score: 3

RE[7]: Comment by jigzat
by lemur2 on Mon 17th Sep 2012 10:00 in reply to "RE[6]: Comment by jigzat"
lemur2 Member since:
2007-02-17

""We are a group of Linux kernel developers (over 400 strong) that develop and maintain Linux kernel drivers. We work with the manufacturers of the specific device to specify, develop, submit to the main kernel, and maintain the kernel drivers. We are willing and able to sign NDAs with companies if they wish to keep their specifications closed, as long as we are able to create a proper GPLv2 compliant Linux kernel driver as an end result."

Wow. Just, wow.

"We Linux devs have finally managed to go far enough in market share that hardware vendors will care about us. Now that we are here, we don't care for the younger OSs that are struggling just like we did before anymore, and will gladly sign NDAs on specs so as to keep an edge on them"
"

The Linux driver project is over five years old. Why didn't you make this complaint back in April 2007?

http://lwn.net/Articles/276973/

"So the LDP was born. It started out as a single place for hardware manufacturers to contact in order to get drivers written for their devices for free. We allowed the ability for companies to sign an NDA if needed to help get over the hurdle that some companies have in releasing their specifications. The NDA process was put into place through the Linux Foundation, and is a 3-way NDA with all of the proper legal documents needed."

The Linux Driver Project would rather not sign an NDA, they would much prefer that companies published programming specifications. However, if a given company insists that an NDA is necessary or there will be no co-operation, then having to sign an NDA over the programming specifications is a small price to pay.

After all, the end product is source code under the GPL. Everyone is free to study that code and determine how it works. Anyone is able even to re-distribute that code, as long as they agree to re-distribute it to others under the same license as they received it. Where is there a problem?

If there is some problem with keeping the GPL driver code open, other parties may still study that GPL code, determine how it works, write a new driver of their own from the knowledge thereby gained, and redistribute their own code under whatever license they please.

Reply Parent Score: 2