Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Mon, 18 Jun 2007 18:49:56 Anders Larsen wrote: > On Sat, 16 Jun 2007 22:54:56 -0300, Alexandre Oliva wrote: > > I don't know any law that requires tivoization. > > Not exactly laws, but pretty close: > > Credit-card payment terminals are subject to strict security > certification, where it has to be ensured that IANAL but I think a second, probably fictional but not unrealistic scenario. A Linux-based in-car entertainment system. I believe there are laws in certain countries that require the front screens to be off when the car is in motion to prevent the driver from being distracted. Assume that the hardware does not prevent the user from uploading modified software (with the restriction removed) and the user modified the system and then causes a crash with fatalities. I imagine there are countries where a civil case could be brought against the manufacturer for failing to provide reasonable safeguards against disabling the safety feature. Cheers, Marek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Mon, 18 Jun 2007 18:49:56 Anders Larsen wrote: On Sat, 16 Jun 2007 22:54:56 -0300, Alexandre Oliva wrote: I don't know any law that requires tivoization. Not exactly laws, but pretty close: Credit-card payment terminals are subject to strict security certification, where it has to be ensured that IANAL but I think a second, probably fictional but not unrealistic scenario. A Linux-based in-car entertainment system. I believe there are laws in certain countries that require the front screens to be off when the car is in motion to prevent the driver from being distracted. Assume that the hardware does not prevent the user from uploading modified software (with the restriction removed) and the user modified the system and then causes a crash with fatalities. I imagine there are countries where a civil case could be brought against the manufacturer for failing to provide reasonable safeguards against disabling the safety feature. Cheers, Marek - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
On Fri, 27 Apr 2007 07:13:08 Linus Torvalds wrote: > I think it could be more interesting if part of the job was doing the > tools. Tools *are* important. Most of my actual _development_ for the last > couple of years has been on "git", not the kernel, but I think I was more > productive that way, so I don't think that's wasted time at all. > > So yes, automation would be a good idea, but I don't think bugzilla is it. <...> > So I really don't think you can compare to "other projects". They simply > don't have these issues. Seems like the bug tracking system needs to be re-evaluated. Perhaps Bugzilla can be modified to better serve the needs of kernel developers. There might be alternatives, JIRA (http://www.atlassian.com/software/jira/) for example. I am sure there are others. Finally, I have over 7 years experience writing various web based systems (using WebObjects, J2EE and others). I would be quite willing to volunteer my spare time and experience if this community decides that a custom written solution (one that would handle email bug submissions/resolutions :) is in order. Kind regards, Marek Wawrzyczny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
On Fri, 27 Apr 2007 07:13:08 Linus Torvalds wrote: I think it could be more interesting if part of the job was doing the tools. Tools *are* important. Most of my actual _development_ for the last couple of years has been on git, not the kernel, but I think I was more productive that way, so I don't think that's wasted time at all. So yes, automation would be a good idea, but I don't think bugzilla is it. ... So I really don't think you can compare to other projects. They simply don't have these issues. Seems like the bug tracking system needs to be re-evaluated. Perhaps Bugzilla can be modified to better serve the needs of kernel developers. There might be alternatives, JIRA (http://www.atlassian.com/software/jira/) for example. I am sure there are others. Finally, I have over 7 years experience writing various web based systems (using WebObjects, J2EE and others). I would be quite willing to volunteer my spare time and experience if this community decides that a custom written solution (one that would handle email bug submissions/resolutions :) is in order. Kind regards, Marek Wawrzyczny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Wednesday 20 December 2006 16:11, [EMAIL PROTECTED] wrote: > On Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny said: > > On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote: > > And if you let yourself get carried away, you can also imagine a little > > multi-platform utility. It would run on a test system collecting PCI IDs > > before submitting them to the site to get the system's overall Linux > > friendliness rating. > > This is a can of worms, and then some. For instance, let's consider this > Latitude. *THIS* one has an NVidia Quadro NVS 110M in it. However, that's > not the default graphics card on a Latitude D820. So what number do you > put in? Do you use: No, no, no... I was never proposing that. I was thinking of something more along the lines of reporting back on open-source friendliness of manufacturers of devices, and perhaps on the availability of open source drivers for the devices. I am talking only about "detected" devices. The database would never try and guess the vendor, model and variation of the system. > (Remember that "users" have different criteria than "developers" - most > users would consider this entire thread "intellectual wanking", especially > since the patch that spawned it got withdrawn. And 'Frames Per Second' > trumps that stupid little 'P' in the oops message. Failure to understand > this mindset guarantees that your computation of a "friendliness rating" > is yet more intellectual wanking... ;) I actually find that trying to obtain information about what hardware is/isn't supported in Linux is actually quite difficult to obtain. The information that's on the internet is either outdated or has not yet been written. I was hoping to analyze the system's device information together with driver/device information obtained from the kernel source itself to give users a better (but not perhaps not as authoritative as I'd like to) picture of what to expect. > And then there's stuff on this machine that are *not* options, but don't > matter to me. I see an 'O2 Micro' Firewire in the 'lspci' output. I have > no idea how well it works. I don't care what it contributes to the score. > On the other hand, somebody who uses external Firewire disk enclosures may > be *very* concerned about it, but not care in the slightest about the > wireless card. Perhaps we just report on the individual devices then... forget the system rating. > Bonus points for figuring out what to do with systems that have some chip > that's a supported XYZ driver, but wired up behind a squirrely bridge with > some totally bizarre IRQ allocation, so you end up with something that's > visible on lspci but not actually *usable* in any real sense of the term... Hmmm... does this happen often? False results are definedly a show stopper. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Wednesday 20 December 2006 16:11, [EMAIL PROTECTED] wrote: On Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny said: On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote: And if you let yourself get carried away, you can also imagine a little multi-platform utility. It would run on a test system collecting PCI IDs before submitting them to the site to get the system's overall Linux friendliness rating. This is a can of worms, and then some. For instance, let's consider this Latitude. *THIS* one has an NVidia Quadro NVS 110M in it. However, that's not the default graphics card on a Latitude D820. So what number do you put in? Do you use: No, no, no... I was never proposing that. I was thinking of something more along the lines of reporting back on open-source friendliness of manufacturers of devices, and perhaps on the availability of open source drivers for the devices. I am talking only about detected devices. The database would never try and guess the vendor, model and variation of the system. (Remember that users have different criteria than developers - most users would consider this entire thread intellectual wanking, especially since the patch that spawned it got withdrawn. And 'Frames Per Second' trumps that stupid little 'P' in the oops message. Failure to understand this mindset guarantees that your computation of a friendliness rating is yet more intellectual wanking... ;) I actually find that trying to obtain information about what hardware is/isn't supported in Linux is actually quite difficult to obtain. The information that's on the internet is either outdated or has not yet been written. I was hoping to analyze the system's device information together with driver/device information obtained from the kernel source itself to give users a better (but not perhaps not as authoritative as I'd like to) picture of what to expect. And then there's stuff on this machine that are *not* options, but don't matter to me. I see an 'O2 Micro' Firewire in the 'lspci' output. I have no idea how well it works. I don't care what it contributes to the score. On the other hand, somebody who uses external Firewire disk enclosures may be *very* concerned about it, but not care in the slightest about the wireless card. Perhaps we just report on the individual devices then... forget the system rating. Bonus points for figuring out what to do with systems that have some chip that's a supported XYZ driver, but wired up behind a squirrely bridge with some totally bizarre IRQ allocation, so you end up with something that's visible on lspci but not actually *usable* in any real sense of the term... Hmmm... does this happen often? False results are definedly a show stopper. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote: > Since `works with' may sound a bit too vague, something like > `LinuxFriendly(tm)', with a happy penguin logo? It would be really cool to see penguin logos on hardware :) I had another, probably crazy idea. Would it be possible to utilize the current vendor/device PCI ID database to create Linux friendliness matrix site? And if you let yourself get carried away, you can also imagine a little multi-platform utility. It would run on a test system collecting PCI IDs before submitting them to the site to get the system's overall Linux friendliness rating. In cases where the system contains devices which do not have entries in the database, the system could look up and use the vendor's Linux friendliness rating. Something like that could really help end users to select the right system and would reward those who do the right thing. Cheers, Marek Wawrzyczny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote: Since `works with' may sound a bit too vague, something like `LinuxFriendly(tm)', with a happy penguin logo? It would be really cool to see penguin logos on hardware :) I had another, probably crazy idea. Would it be possible to utilize the current vendor/device PCI ID database to create Linux friendliness matrix site? And if you let yourself get carried away, you can also imagine a little multi-platform utility. It would run on a test system collecting PCI IDs before submitting them to the site to get the system's overall Linux friendliness rating. In cases where the system contains devices which do not have entries in the database, the system could look up and use the vendor's Linux friendliness rating. Something like that could really help end users to select the right system and would reward those who do the right thing. Cheers, Marek Wawrzyczny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
Dear Linux Kernel ML, I am writing as a Linux-only user of over 2 years to express my concern with the recent proposal to block out closed source modules from the kernel. While, I understand and share your sentiments over open source software and drivers. I fear however, that trying to steamroll the industry into developing open source drivers by banning closed source drivers is going to have a completely different result. They will simply abandon Linux support for some of their products altogether. Take the high-end graphic cards that are prevalent in most of today's home/SOHO hardware- desktops and laptops. Would I be wrong in saying that the Linux market share in this market is no more than 5%? These companies have already demonstrated that the support they provide is proportional to the market share. The open source driver development is promising but it has been mentioned several times that the project is undermanned and the vendors are not forthcoming with the necessary information. My hardware as it stands today is still not working with the open-source drivers. Perhaps this is the case of PEBCAK and not the open-source drivers per se but with a 1-4 hour turnaround to test a new version of the r300 driver it is not a small effort on my part. Still, I'm eagerly awaiting the day that I'll be able to use an open-source driver that is on par with the ati one. The bottom line is that the proposed 1st Jan 2008 dead line is unlikely to make any corporations tremble. It is likely to be the day when I will be no longer able to run the latest version of the kernel. Finally, I'd like to thank you for reading my email and on your work on the fantastic work and community that Linux is. I hope you will take this user and others like me under consideration when making the final decision on whether or not to include the proposed patch and whether to undertake work on code that will prevent binary drivers from loading. Warmest regards, Marek Wawrzyczny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
Dear Linux Kernel ML, I am writing as a Linux-only user of over 2 years to express my concern with the recent proposal to block out closed source modules from the kernel. While, I understand and share your sentiments over open source software and drivers. I fear however, that trying to steamroll the industry into developing open source drivers by banning closed source drivers is going to have a completely different result. They will simply abandon Linux support for some of their products altogether. Take the high-end graphic cards that are prevalent in most of today's home/SOHO hardware- desktops and laptops. Would I be wrong in saying that the Linux market share in this market is no more than 5%? These companies have already demonstrated that the support they provide is proportional to the market share. The open source driver development is promising but it has been mentioned several times that the project is undermanned and the vendors are not forthcoming with the necessary information. My hardware as it stands today is still not working with the open-source drivers. Perhaps this is the case of PEBCAK and not the open-source drivers per se but with a 1-4 hour turnaround to test a new version of the r300 driver it is not a small effort on my part. Still, I'm eagerly awaiting the day that I'll be able to use an open-source driver that is on par with the ati one. The bottom line is that the proposed 1st Jan 2008 dead line is unlikely to make any corporations tremble. It is likely to be the day when I will be no longer able to run the latest version of the kernel. Finally, I'd like to thank you for reading my email and on your work on the fantastic work and community that Linux is. I hope you will take this user and others like me under consideration when making the final decision on whether or not to include the proposed patch and whether to undertake work on code that will prevent binary drivers from loading. Warmest regards, Marek Wawrzyczny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
