[Lancaster] Re: Help -- Video importing/processing software

[Ken Hough]

Martyn,

I hear all of the points that you make, but the fact is that we are 
presently left with a less than satisfactory situation where users 
suffer and a previously willing helper has been pissed off. Maybe he is 
now behaving like a big baby, I don't know. Maybe he isn't the only one.

In order to gain full functionality of my webcam, I have no choice but 
to use Microsoft Windows. That irks me!

Living in an idealists world where practical compromises are not 
allowed, can only damage the image of Linux in the eyes of would be 
USERS. Idealism is fine to determine goals, but in my (now rather long) 
experience is NEVER 100% workable in the real world.

Do you really believe that the likes of Philips are going to pay any 
attention to a relatively small bunch of guys who are effectively 
DEMANDING that they change their ways?

I come back to my point about 'hearts and minds'. The best way to grow 
Linux has to be to accomodate the likes of Philips and other top class 
hardware suppliers. They all have a vested interest in keeping Microsoft 
happy which in turn means not promoting Linux.

I have used Linux almost exclusively now for several years and wish to 
continue with it. I do not wish to recompile my kernel, although I have 
done this in the past. It would be nice not to have to go through the 
processes of ./configure, make and make install (only to discover that 
various packages are missing) to gain some additional functionality. OK, 
I know there are reasons why, but this is not for essencially non 
technical users.

I DO wish to see the Linux user base grow. I'm reluctantly beginning to 
believe that growth will remain limited untill there's a change of 
attitude on both sides and that this must come first from the Linux side.

Ken Hough

Martyn Welch wrote:

>On Wednesday 02 August 2006 08:59, Ken Hough wrote:
>  
>
>>Martyn Welch wrote:
>>    
>>
>>>The kernel maintainers don't want them - once a binary blob has been added
>>>to the kernel it becomes very difficult for them to debug crashes and
>>>alike, it also becomes quite hard to deal with on the licensing front. I
>>>understand that people want good hardware compatibility, to use the
>>>"best" hardware available and (sometimes) use Linux. The problem is
>>>without the hardware being openly documented this becomes virtually
>>>impossible in an opensource context.
>>>
>>>The solution is to spend your money wisely, support those companies
>>>willing to give you enough information to allow you to use the device you
>>>purchased in whatever manner you see fit. Even if this does mean using a
>>>device not considered to be the "best" on the market - lets face it, it's
>>>only the "best" choice for you if it works...
>>>      
>>>
>>I have little choice, especially as I intend to carry out already
>>documented hardware mods to the webcam. This make/type of webcam is
>>recognised as being simply the best for the job. Other makes don't even
>>come close.
>>
>>    
>>
>
>Yeah - same problem I face some times. Niche fields don't generally have the 
>clout to get what they want/need, unless of course they have *lots* of money.
>
>  
>
>>I understand the philosophy that you describe, but we live in the real
>>world. Surely, the best way to propagate Linux is to encourage people to
>>use it and that means enabling them to use the best available hardware.
>>    
>>
>
>I disagree, I think that the best way to propergate Linux is not to overly 
>dilute what it stands for and if people find it a compelling alternative then 
>they will use it.
>
>Linux is growing in popularity in the real world without diluting. It doesn't 
>ask for, or take the same approach that is taken by proprietary software 
>vendors but that is one of the things that many like about it.
>
>I am strongly of the opinion that specs for interfacing to hardware should be 
>readily available to those who buy the product and in a way the Linux 
>approach is helping to encourage this.
>
>The issue of hardware compatibility is a real world problem and Linux provides 
>one approach to solving it - provide open specifications for communicating 
>with hardware.
>
>  
>
>>When we have a guy who is doing his best to provide help despite being
>>stapped by a NDA, and there is no alternative to hand, then surely it is
>>foolish to kick him in the teeth. If it wasn't for him, I would have no
>>alternative but to use MS Windows.
>>
>>    
>>
>
>I've done some extra reading around this subject since I made my last post, it 
>seems that the NDA had expired, so as far as I can tell he is legally in a 
>position to release the compression code as GPL. He didn't want to as 
>Philips, who make the chipset, are still using it in current devices and 
>licensing the technology to others, he doesn't want to rock the boat. I 
>rather doubt that Philips would be overly concerned if the shoe had been on 
>the other foot.
>
>I seems that the driver is back in the kernel (Alan Cox has taken on the 
>maintenance) and some basic reverse engineering has been done to include the 
>functionality of the originally non-GPL-d portion, though there seems to be 
>some further disagreement over the process used.
>
>Interestingly there is some debate as to whether the kernel should have the 
>compression code in it at all, there are some who believe that the kernel 
>should pass the uncompressed stream to userland for decompression. This 
>approach would probably by-pass most of the problem.
>
>  
>
>>Webcams are now a common part of desktop computer systems.
>>
>>    
>>
>
>I've just been looking for one with good Linux compatibility - they're harder 
>to find than working wifi cards!
>
>  
>
>>Only, when more hardware suppliers realise that there is a meaningful
>>base of non Microsoft users will the situation change for the better. We
>>need a 'hearts and minds' approach. That's not going to happen with a
>>purist 'head in the sand' approach from the
>>Linux community.
>>
>>    
>>
>
>The danger is that the Linux environment is treated the same as the 
>proprietary software world, by which I mean that they produce half-baked 
>closed drivers. OK if you want the hardware to work with a standard x86 
>computer, really bad if you happen to use the powerPC processor or something 
>like the xscale. Also a bitch to fix and maintain as the kernel evolves, 
>leading to loss of compatibility when the producers decide to stop supporting 
>it.
>
>  
>
>>IMHO, it is plain stupid to discourage help from the one available source.
>>
>>    
>>
>
>It must be noted that he was disobeying the rules with regards to including 
>code in the Linux kernel. The rules state that hooks solely for loading 
>binary blobs into the kernel are not allowed. He didn't follow the rules and 
>now he's acting a bit like a big baby.
>
>  
>
>>The use of 'ndiswrapper' allows commercial wifi drivers to be used under
>>Linux. I know that this does not involve a kernel patch, but as I wrote
>>in my previous message "Where there's a will.....".
>>
>>    
>>
>
>Which is an interesting case study.
>
>Ndiswrapper is not included in the stock kernel exactly because of this issue. 
>Sure many of the distributions add it, but it's not in the vanilla kernel. It 
>is maintained as an add-on, the original writer of the pwc driver had this 
>option but didn't want to use it.
>
>Martyn
>
>  
>