Re: Results of "downloading compressed program images" request

["Robert J. Brown" <rj@eli.elilabs.com>]

>>>>> "Carl" == The Chazman <chaz@devastator.extern.ucsd.edu> writes:

    Carl> RMS replied:
    >>  >> me in many instances.  Why not give away the source code?
    >> It is >> useless without the hardware to run it on.  > >I think
    >> you're right--I wish that more embedded developers had this
    >> view.
    >> 
    >> then how do you protect a proprietary hardware design
    >> 
    >> In general, if something makes it hard for people to keep the
    >> specs of hardware secret, I would consider that a step forward.
    >> The concealment of hardware designs for PC hardware has been a
    >> great problem for the free software community.  I have little
    >> sympathy with someone who wants to keep hardware specs secret
    >> merely so as to beat out someone else.
    >> 

    Carl> I would agree with you wholeheartedly if we were talking
    Carl> about PC hardware, but we are not.  The situation with
    Carl> embedded hardware is entirely different, having near-zero
    Carl> need for the end-user to know anything about the hardware.

It is not always the end user that wants to know.  See my comments
below...

    Carl> #1) Generality of hardware components

    Carl> PC hardware is generic.  One buys a video card, a SCSI
    Carl> controller, a hard drive, etc.  One can buy each one
    Carl> separately, plug them into each other, and expect them to
    Carl> work.  Parts are interchangable and replacable.

    Carl> Embedded hardware is not generic.  The entire system is
    Carl> designed as one whole piece, with no interchangable or
    Carl> replacable parts.  One generally cannot add any new hardware
    Carl> functionality after the fact -- it is not an upgradable
    Carl> system (except maybe software-only upgrades as now programs
    Carl> are increasingly stored in flash).

    Carl> Hardware specs for embedded products don't need to be
    Carl> released because you can't upgrade them.  Since you can't
    Carl> replace a component, the end user will never need to go
    Carl> looking for a driver for the new component, so the OS
    Carl> maintainers will never need to write any drivers for any new
    Carl> components.  All that is required is that the original
    Carl> hardware be supported, which, if the product is shipping,
    Carl> obviously it is.

Actuall, a more accurate statement would be, "You can't upgrade them
because the specs aren't released."

    Carl> #2) Generality of purpose

    Carl> A PC can be used for anything.  One can play any number of
    Carl> games on it, develop both software and hardware on it, host
    Carl> web/ftp/other services on it, or do just anything else a
    Carl> computer is capable of.  As the uses of a PC change, it can
    Carl> be upgraded to have more resources and hardware to meet the
    Carl> needs of its new uses.

    Carl> An embedded system was designed to do exactly one thing.  It
    Carl> has exactly the bare minimum resources and hardware required
    Carl> to accomplish its one task.  It has no means to do anything
    Carl> else, ever.  If a 6502 (remember the Apple II+?) has enough
    Carl> CPU power to manage the task at hand, that's what will be
    Carl> used.  If the task requires 2k of RAM, 2k of RAM is what's
    Carl> resident, and no more.  If the status of the box can be
    Carl> effectively conveyed by three LEDs, then there will be no
    Carl> screen of any kind, just three LEDs.  It cannot be upgraded,
    Carl> but that's irrelevant -- its task will never change.

Its task will never change because no one has the information to
change it.

    Carl> Hardware specs for embedded products don't need to be
    Carl> released because the product's task will never grow or
    Carl> change.  Thus, one would never need to write completely new
    Carl> software for it (just patch the old software).  Never
    Carl> needing to write completely new software, an end user would
    Carl> not need to know the software interface to the hardware.

This statement makes a falacious assumption.  You don't know *WHAT*
the end user wants.  All you know is that if he bought your product,
he thought it was the best he could do towards meeting his
expectations.  It means you came closest, not that you met them all. 

    Carl> Admittedly, there are recent products that blur the line.
    Carl> Things like handheld PCs and programmable organizers
    Carl> (e.g. Palm Pilot) are somewhere in-between the generality of
    Carl> a classic PC and the fixed design of a classic embedded
    Carl> system.  Thus, I feel that the accessibility of hardware of
    Carl> these intermediate devices needs to be significantly greater
    Carl> than that of the more single-minded devices I speak of when
    Carl> I say "embedded products", like VCRs, microwave ovens, or
    Carl> automobile engine controllers.  I make my point for these
    Carl> single-minded devices, which are the vast majority of
    Carl> embedded systems.

Lets talk about a major embedded market, since you brought it up,
Lets talk about the automotive market.  Lets also talk about the
automotive aftermarket!  Just because Delco made an engine controller
that was the best fit to satisfy most of the people most of the time,
this does not mean that there could never be a better solution for
some of the people some of the time.  

Example: people like to use cars in different ways.  Some people like
to race them.  The engine controller probably has a number of
excellent features designed into it to make the car generate low
levels of pollution, last a long time, get good mileage, etc.  If I am
racing that car, I don't care about those features.  To me they are
bad, not good.  I want high power and torque output, high rpm, etc.
If I am racing in a stock class that requires me to race a production
automobile, with certain allowable modifications, I do not want your
firmware, even thought it is an excellent choice for most drivers of
that car.

I want custom firmware.  The indeed exists a market for such custom
firmware, but much of it is done by reverse engineering and
dissasembly of the roms supplied by the factory.

Far better would be an open system where the hardware specs were
published, and the software was GPL-ed.  Now people with unusual
requirements can have those requirements met in a professional
manner.  A proper market for aftermarket firmware would develop,
thereby making cars equipped with that engine controller more
attractive to specialist users, while still keeping the average user
satisfied with the default factory supplied firmware.

This is essentially what IBM did with the architecture of the PC, and
they created a huge clone market for hardware as well as making the PC 
the de facto standard.  

You want to sell automotive control systems?  Sell open systems.
Increase the value of your product thereby.  Watch your market grow to 
beat out the closed system competition!

    Carl>                    ----- Carl N Miller
    Carl> (chaz@devastator.extern.ucsd.edu) Embedded software
    Carl> development pays the bills, Linux free software development
    Carl> occupies the free time.

-- 
--------  "And there came a writing to him from Elijah"  [2Ch 21:12]  --------
Robert Jay Brown III rj@eli.elilabs.com  http://www.elilabs.com 1 847 705-0424
Elijah Laboratories Inc.;  37 South Greenwood Avenue;  Palatine, IL 60067-6328
-----  M o d e l i n g   t h e   M e t h o d s   o f   t h e   M i n d  ------