[Openicc] Drop size calibration

[Hal V. Engel]

On Monday 04 February 2008 16:34:51 Robert Krawitz wrote:
>    From: "Hal V. Engel" <hvengel at astound.net>
>    Date: Mon, 4 Feb 2008 15:17:40 -0800
>
>    On Monday 04 February 2008 12:13:42 edmund ronald wrote:
>    > It would appear that Barbieri see themselves as a pure manufacturer of
>    > hardware -not software- and would like to set open interface
>    > specifications and export measurements a L*a*b* values, but
>    > unfortunately some of their "firmware" runs on the host platform and
>    > they cannot expose the source to this code  for a reason which I
>    > haven't been told.
>
>    Much of the hardware that is out there now (not just these
>    measurement devices) have significant functionality implemented in
>    software on the host machine.  This is true for the EyeOne devices
>    and it appears to be the case with the Barbieri hardware.  These
>    bits of code are the "secrets" that the vendors are trying to hide
>    and protect in the device interface libraries/drivers and this
>    functionality is probably only about 5% to 10% of the code in the
>    library.  In the past hardware vendors would have implemented this
>    same functionality directly in the hardware.  By moving this to the
>    host computer they reduce the cost of producing the hardware
>    significantly and they gain the flexibility of being able to
>    improve the "firmware" by simply creating new versions of the
>    interface library/driver that have improved code for this
>    functionality.
>
> They're running their firmware on my open system.  If it's running in
> kernel mode, it has access to the entire system. 

I don't think any of the "firmware" that is used by these measurement devices 
is going to need anything other than user mode access.   For the most part 
this "firmware" is virtual in that it is code that is doing things that would 
have happened in the device hardware in earlier versions of these devices but 
now is being done on the host machine in software.  This is more like a Win 
modem than the firmware that loaded up by the kernel for some Intel CPUs.
  
> I don't particularly 
> want to be unable to audit code with superuser or kernel level access
> that's running on my system.  I have no way of knowing that it's not a
> rootkit or something else destructive.  In the Windows world we've
> seen vendors with outright malicious code (think the infamous Sony
> rootkit -- it took action to hide itself and make itself hard to
> remove.  That qualifies as malicious in my book).  I don't see why I
> should trust the vendor if the vendor won't trust me.

I agree with all of this.

>
> If it's running in a carefully isolated virtual machine it's probably
> safer, but I'm still out of luck if the virtual machine won't run on
> my physical machine (for example, if the virtual machine is built for
> x86 running Linux and I happen to be running Solaris, or Linux on
> SPARC, or what have you).
>
> Furthermore, kernel-based drivers, even if not malicious, have the
> additional problem that the kernel binary interface is not stable.

None of these devices are going to need kernal level drivers.  These devices 
are designed to work with the existing serial and/or USB ports and as long as 
those ports and their drivers work to spec the device will function assuming 
there is code available to drive the devices.  So this is not a concern.

> Linus, and the other top Linux kernel people, have consistently made
> it very clear that the kernel binary interface is subject to change
> without notice, and nobody will be willing to debug it (or help me
> debug it).
>
> Finally, binary-only software of any stripe carries the risk that the
> vendor will stop supporting it going forward, and I can't help myself
> against that.  If Graeme were to stop supporting Argyll I would at
> least have the source code and could do something about it; if I were
> to be hit by a bus, others could similarly pick up Gutenprint and
> support it.  If the vendor were to go under, I'd be stuck.

And this concern is very real.  Many Linux users have been burned by hardware 
vendors who promised to provide drivers and either did not or only provided 
binary blobs and then stopped supporting the hardware leaving users who 
purchased thier hardware stuck with hardware that was useless.  If you took a 
poll here perhaps 20% to 30% of us have had this or something similar happen 
to us. 

>
> Are those enough *pragmatic* reasons for rejecting closed source
> binaries?  I'm going to stick with something fully supported by Argyll.
>
>    The underlaying issue that we are dealing with is that none of
>    these vendors have figured out how to hide these details in an open
>    environment and this is something that we need to work with them to
>    resolve.  Either there is some way that will allow them to continue
>    to hide these details without being too expensive or they need to
>    come to grips with working out in the open.
>
> Basically, it's really hard to hide this kind of stuff in an open
> environment, and that doesn't particularly bother me.  Hardware
> vendors can survive in an open environment; they just have to be
> willing to think outside the box (no pun intended).

Actually I think they can thrive (not just survive) in an open environment if 
they have the right attitude.

>
>    We have seen this same issue with other vendors for other classes
>    of hardware in the past.  A number of these vendors have decided to
>    work in the open and none have suffered any ill effects from doing
>    so.  If anything exactly the opposite has been true since the open
>    source community embraces any company that takes this route.  But
>    most hardware companies have an initial mind set that prevents them
>    from embracing working out in the open because they have convinced
>    themselves that they will be harmed by doing this even if there is
>    no evidence that this is in fact the case.
>
> Yes -- like printers.  In the early days of Gutenprint, Epson provided
> very little information (their manual for the 1998 4-color printers
> stated that the technique to achieve 1440x720 DPI resolution was
> proprietary).  These days, Canon and Lexmark still provide no
> information at all, and everything has to be reverse engineered.  HP
> provides true open source drivers for most of their printers, but
> they're somewhat limited.  I'm not interested in going back to the bad
> old days.  It's entirely too much of a hassle.

Another set of examples are Intel and AMD.   Intel has been very active on the 
open source front for sometime and has been actively funding open source 
projects to support their hardware (both CPU andd GPU).  AMD management is 
conviced that one of the major reasons for the success of the AMD64 was how 
accepted this processor was in the open source world.  One of the reasons 
that this happened was that AMD worked with the kernel team and the gcc team 
to make sure that the processor worked correctly and was fully supported by 
our open systems.  This success is one of the reasons that AMD is now working 
so hard to do the same thing for the ATI GPUs now that they own ATI.  Both of 
these companies are competing for the open source market segment and one of 
thier major marketing tools is being actively involved in making sure that 
there are open source drivers and support for thier hardware and doing this 
in a way that they are seen as being part of the open source community.  This 
is how hardware vendors can thrive in this market segment.

Hal