On Tue, Apr 08, 2008 at 01:14:51PM +0530, JoJo jojo wrote: > On Tue, Apr 8, 2008 at 12:12 PM, Greg KH <greg at kroah.com> wrote: > > Exactly, it's not a simple "oh look, these drivers came exactly from our > > efforts" type of thing. The reach and range of this effort is already > > quite large, trying to quantify it for no good reason isn't something > > that I'm going to worry about. > > > > In the end, what would it really achieve? > > > > This is where the project management function is failing, > if you can't quantify the progress made (or lack thereof), > you can't take proper corrective action for strategy. > (ex. Last year we wrote 10 drivers, this year we will write 11 drivers, > now if we say there are 1000 drivers yet to be written, then clearly > the current strategy needs rework, this decision can only be based > upon accurate > indication of progress made, on the other hand if there are only 14 > drivers yet to be written, > then the current strategy is fine, write 11 drivers this year.) So you are trying to say that a single driver is the unit of measurement against which this project should be judged? So, is one USB-IR remote control driver equal to a 3d graphics driver? Or how about a single device id added to an existing driver vs. a company opening up the specs for a whole class of devices? See, it doesn't really work that way here :) > ....or do you rather prefer walmart releasing their annual report as > "oh we made some profit this year." I'm not a for-profit entity, and do not have to generate "revenue" to be able to work on this project. And neither should anyone else. > > > b) You need to segregate the LDP targets into 2 categories > > > Enterprise endusers & Non-Enterprise endusers. > > > > I do not believe in those two categories at all. > > > > well I do, > "Enterprise endusers" will quickly find their latest storage(SAN etc) > h/w linux drivers, > getting improved all the time, with the vendor paying for it directly > > "Non-Enterprise endusers" will always find their gadget, not working, > not working correctly, not full featured. Is this the case that you have found in the past? I sure have not. > the above is a typical classification of h/w & support level, and is > very applicable to all h/w Again, I disagree. > > The goal is "drivers for all devices from any manufacturer that wants > > them." We do not descriminate by market share or anything else. > > Manufacturers will do the bare minimum required, needed to make them money, > (usually referred to as cost-benefit analysis). > > Are you saying that an enduser, should not expect to be able to use > the h/w how he wants to > but only instead as manufacturer intended ? (vendor lock-in?) No, where did you get such an outrageous claim from my above statement? > if manufacturers want to provide the enduser with Linux drivers its fine, > if he does not provide linux drivers, the enduser should not use the > h/w with Linux ? No, where did I claim this? > Manufacturers usually show this level of concern (we need linux > drivers of our h/w), only for their big customers (read "enterprise > endusers"). Some do, some don't. They are all different. > > "war"? This isn't a "us vs. them" type thing at all, despite the human > > nature of always wanting to create such a story to explain things. > > just a term to signify the urgency of a tangible longterm solution. A false term that should not be used for such matters. > > > Please work to centralize the H/W compatibility list, every distro is > > > rolling their own...its all a mess > > > > That is outside the scope of our effort, sorry. > > Then the scope needs to be corrected for this project to succeed doesn't it ? > (or is the scope set in stone ?, disregarding the ground realities) Who is judging "success" here? You, or me? Or someone else? When did I ever say "we really need to have a list of all hardware that works for Linux in order for this project to succeed!"? Sorry, not going to come from me, see my other posts directly stating that I think this is a bad idea and one that will never work out. So, with that in mind, I guess I have "failed" in your eyes. So I can now get back to doing the work that I wanted to do :) > > > e) reverse-engineering is _THE_ opensource way, (going back to the > > > time of PDP ?) > > > do you agree to the above statement, as a spokesmen for Linux as a OS? > > > > I am a spokesman for no one but myself, and that statement doesn't make > > any sense to me at all. > > > > well Novel recognizing your efforts, and hiring you to continue the good work, Novell did and does not "hire me to continue this work". They happen to let me do this work on company time, and I am very grateful for that. It does not mean I speak for them in any manner in this forum. > makes you a representative of sorts, that knows whats good for the community. Heh, yeah right :) > (most of the early FSF utilities started with reverse engineering, > & they kept up reversing all new features of the closed source ones, > thats what I was referring to) And again, the statement does not make sense to me, sorry. > > > g) there's a reason manufacturers don't bother with documentation, > > > they make a IC in a batch, and if they only have order for 1 batch > > > run, why bother with documentation, > > > just fab it and forget about it, is their attitude. > > > > That is not true, having worked with many manufacturers in the past and > > present. > > > > Well thats the answer I got from a manufacturer I contacted, > so yes that is True. (and I am not just hand waving in the air here ;-0) We both seem to have a dataset of at least one. Luckily my set contains more than one, and seems contrary to yours. Doesn't mean that either of us is correct or incorrect, but the manufacturers that tend to want their devices to be used and built into designs, usually have some kind of documentation around to help faciliate it. The ones that do not tend to go out of business rather quickly :) > > Either way, the very capable, and active developers of the > > linux-wireless projects are working to resolve all of the wireless > > driver issues. If you have questions or concerns about these types of > > devices, please contact them. > > > > the linux-wireless developers are still sticking to NDIS wrapper > approach, (well some of them are ;-) > Even if you didn't want them to use those GPL symbols, they still > continue, they have no choice. > > Another possible strategy I would suggest, is to increase the number > of Linux driver developers 3 fold, > an increase like that would have appreciable effect on demand on Linux > Drivers (decrease). We have been increasing the number of unique contributors to the Linux kernel constantly over the past 5 years. See my recently published paper for proof of that. thanks, greg k-h
