Re: Demise of the COM port?

From: Paul Carpenter (paul$_at_pcserv.demon.co.uk)
Date: 04/03/04 

Date: Sat, 3 Apr 2004 10:17:45 +0000 (UTC)

On Saturday, in article <1080979389snz@amleth.demon.co.uk>
     peb@amleth.demon.co.uk "Paul E. Bennett" wrote:
>In article <cu1brmauhv3.fsf@nokia.com> darin_@_usa_._net "Darin Johnson" writes:
>> Chris Hills <chris@phaedsys.org> writes:
>>
>> > The problem is that neither Linux or FreeBSD == money :-(
>>
>> It does equal money, because the products get purchased!
>> Now maybe they think the potential market is too small to
>> justify the cost of driver development, and that's understandable.
>> But that doesn't mean they can't relese the specs for free.
>
>I'm with Darin on this. I'd also add that if everyone of us that use one
>of the alternative OS's as a development platform would make it known at
>the shows then word will eventually filter back and they may get the
>feeling that the market segment is growing sufficiently for them to start
>taking an interest. So all of you who use an alternative OS (even briefly)
>go make it known.

Yes the more people who tell them they are losing potential sales will
eventually get through, however unless more than 10% at EACH event tell
them this, the drones will not pass it back. Most of the drones automatically
assume everybody is running the latest version of Windows on the latest
hardware.
 
>> The people who use Linux, BSD, or other free OSs are _not_
>> cheap spenders.
>
>Despite the inexpensiveness of the software product I suspect many of
>us spend more money on getting decent dependable hardware to run it all
>on. I am currently planning the final consolidation of all of my
>development tools on to one type of platform (which is having to be done
>as a spare time activity). There is a vast quantity of data, old designs
>and archived material that has to be transferred in a manner that will
>ensure data integrity.

That can be a pain for products even under Windows, especially if you have to
support products for longer than five years, as often happens some parts still
need supporting when newer tools or the parts themselves are no longer around.

Still keep a working Windows for Workgroups to support some products for that
reason.

>> > Most commercial companies will see that market as a black hole and no
>> > profits. They probably also think that the minute they get anywhere
>> > Linux that their source code will end up on the internet.
>>
>> That's just silly. If they're not selling the drivers, why should
>> they care who sees the source code? The source code is useless
>> without the hardware to go with it, and in the vast majority of the
>> cases has no significant ideas that another company could steal in
>> order to gain a competitive advantage.

Seeing the source code is historically a big no-no for many reasons, ranging
from the drones don't want to find out if it is possible, to being scared
that somebody might see what a kludge they have done.

Also they miss out on all the chance of getting you to agree to Software
License, registering on their web site, phoning home from their driver......
Let alone adding unneccessary pop up applications.

>Especially in the case where they are using, essentially, a common
>interface standard. They may have variations in the protocol but
>by making the interface detail properly available they would actually
>sell more product to a wider audience. So long as they produce decent
>dependable interface information someone like myself will not need to
>bother their tech support at all. Yes they should provide such info
>for free to promote wider sales.

See above on 'kludges'.
 
>> If they don't want to let out source code, and don't want to create
>> their own drivers, then they should just release some specs so that
>> someone else can write their own drivers.
>
>An alternative approach would be to ensure that their product was
>able to supply the device driver (byte coded) to a system running
>Open Firmware. That way, at boot time, the interfaced device could
>just download it's driver to be compiled on the OF based system
>no matter what OS was running over the top. I know there may be a
>few issues around loading drivers after the system is up and running
>for the hot-plugable devices but that should be reasonably easy to fix.

Any form of encryption (even byte coding) is reversable with enough time
and effort. Remember you are talking about what in reality is low margin
stack it high methods of sale, where the specs could change every three
months. 

-- 
Paul Carpenter		| paul@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/>        Main Site
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info.
<http://www.badweb.org.uk/>             For those web sites you hate.

Relevant Pages

  • [BUG] panic 2.6.20-rc3 in nf_conntrack
    ... When I shut down my ppp0 interface the kernel ... This kernel had the ipp2p patch from patch-o-matic-ng applied, ... # Firmware Drivers ... # ACPI Support ...
    (Linux-Kernel)
  • VESA fb weirdness in 2.6.0-test4-mm4
    ... Vesafb is announcing itself as: ... quite slow, but compared to *cough* some other fb drivers, it is at least ... # ACPI (Advanced Configuration and Power Interface) Support ...
    (Linux-Kernel)
  • Re: [linux-pm] [patch] pm: fix runtime powermanagements /sys interface
    ... For PCI devices that support low-power states, ... interface is admittedly lacking in that respect. ... have drivers bound to them that implement it). ... power states are inherently specific to the bus that they are on. ...
    (Linux-Kernel)
  • Re: Demise of the COM port?
    ... feeling that the market segment is growing sufficiently for them to start ... >> Linux that their source code will end up on the internet. ... If they're not selling the drivers, ... by making the interface detail properly available they would actually ...
    (comp.arch.embedded)
  • Re: Adding an async I2C interface
    ... In order to support this async operation, ... modified the piix4 and the i801 drivers, I probably won't do any more ... this still supports the old driver interface, so no drivers need to be ...
    (Linux-Kernel)