[argyllcms] Re: More on instrument access
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Tue, 08 Jan 2008 23:45:46 +1100
Nicolas Mailhot wrote:
Not true. I have been even handed in the comparison -
Argyll has been packaged for none of these systems,
And that's not fair. You can't compare a no-packaging approach for
systems designed around packaging and systems were packaging is an
afterthought.
Well I think is is fair. Since when have UNIX based systems
needed installers or packaging to run an application ?
It's MSWindows based systems that seem most attached to
requiring such things. The bottom line, irrespective of
how things are or are not packaged, is that noone knows how to install
color instruments on all the Linux distributions in a way that
allows them to be accessed by user programs. Several people have
solved their own problems, but these solutions do not appear
to work for others.
It's not cheating and that's just a different social organization.
You're still trying to centralize all argyllcms related work when
Linux organization is more distributed.
Centralized is generally the way applications are. Having
to depend on distributions to make an application work
is simply inefficient and adds unacceptable dependencies.
It is really covering up some significant issues
in Linux as an application platform.
See
<http://autopackage.org/faq.html?PHPSESSID=d25dcaf01b9e82a2137c69387b12c8ae#3_1>
for a more detailed explanation of the issues.
since this then requires nearly 10 times the human
resources as the other platforms.
Untrue. That just means the expertise is distributed among more
organizations instead of one entity with the same number of people
behind a high-$$$ call number.
The point is that such expertise shouldn't be required. It should
be possible to create an application for Linux, and it
should then run without change on all (architecturally compatible)
distributions of Linux.
That's also completely false. There is a high standardization drive,
but it does not rely on one monopolistic vendor doing all the
decisions but on actors agreeing on common solutions. So software
ecosystems whose ISVs work together are highly standardized, and
software ecosystems like color management where actors wait for
someone else to design the infrastructure get nowhere.
It's basically asking a lot of a developer like myself to not
only be an expert in a particular field (color science,
numerical algorithms, electronic engineering, reverse engineering,
application development), and then have to become an expert in
USB subsystems, X11 internals and the Linux kernel + all the politics
of having patches accepted into such social organizations, in order
to add necessary API's. It's basically incredibly inefficient to ask
such things of everyone, rather than having experts in certain areas
do what they are expert at. The difference in productivity between me
sitting down to add features to X11 or the kernel and an existing
expert in that area doing it are something 50:1 or much worse,
simply because of the learning curve, and while I'm doing that I'm not
doing what I'm expert at, so the opportunity cost is even higher.
Every time a big non-Linux app is ported there there is a multi-year
painful phase where the ISV has to do all kinds of adjustments to
adapt its app to standards it was not expecting because the
corresponding domain is a huge mess on non-Linux platforms.
Maybe, but what's that got to do with Argyll ? Argyll is a cross
platform, command line application, and has been since its inception.
I think that Linux development is on a seriously wrong track
if it's got to the stage that an executable can't be run
on it without some sort of packaging.
> You've just been dismissing all kind of conventions because they don't exist
on other systems so you feel you can get by without them.
I currently have many projects to work on, and can't afford to be
side tracked with things that are too specific to one particular
platform or distribution. I also value robustness a great deal,
which is why I much prefer statically linked executable rather than
getting tangled in "Shared library Hell". I also think that for Linux
to mature, it probably needs to get past the current "distributions"
approach and onto a "platform" approach, and I'll be doing my best to
encourage such a change.
> So don't
complain of lack of standardisation. There are standards like on other
systems, the standard map is just different.
I don't think I'm complaining, I'm pointing out areas that can be
noticeably improved if Linux is to become on par with other alternatives.
If feedback from "customers" isn't listened to carefully, then they
will look elsewhere.
Graeme Gill.
Other related posts:
