[Openicc] Drop size calibration

[Robert Krawitz]

   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 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.

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.
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.

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).

   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.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton