[argyllcms] Re: More on instrument access
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Tue, 08 Jan 2008 10:14:22 +1100
Nicolas Mailhot wrote:
Apples to oranges comparison. You're comparing systems where you
follow the preferred deployment process with systems where you're
intentionally working against it.
Not true. I have been even handed in the comparison -
Argyll has been packaged for none of these systems,
no installers were used, none of the platforms
preferred deployments were used. I'm using the most basic,
reliable deployment process - copy the executable to
the system, and run it.
An app that has followed the proper
packaging process does not require users to edit configuration files.
That merely hides the problems, they still have to be
solved by whoever packages the application or creates
an installer.
An editor that is working with distributions does not need to guess
the working udev syntax for every distribution out there by itself.
This is one of the issues. I'd like to deploy a single installation
that works on all Linux distributions. As a non-expert in
any particular Linux distribution, how do I do that ?
It's basically "cheating" to expect that there will be one
expert per Linux distribution to package the application,
since this then requires nearly 10 times the human
resources as the other platforms.
The Huey is a sore point and it was blacklisted on request a few days
once the demand was done using proper channels (no idea for how long
you knew the problem and tried to fix it outside the community
before).
Again, I completely disagree with this. The Huey doesn't need
black listing (there was an issue with detaching the kernel
driver that was sorted out), and it will make supporting it more
naturally (using the HID driver) more difficult in the future.
If you want to be fair measure how long it takes for a lambda windows
user to write a .reg or .ini file.
It took practically no time to "write" the .ini file, since libusb-win32
provides a utility to generate a boilerplate. Taking it's boilerplate and
changing
the PID/VID is trivial, and it works on a wide range of MSWindows versions
(Win2K, WinXP, WinVista). If Linux's solution to device permission problems
were as simple as it was to modify the libusb-win32 .ini file,
and worked as reliably, there wouldn't be any problems.
When they embark in a "let's replicate the way I work under windows
despite everyone telling me this system conventions are different" yes
it's painful. Linux is a community OS. Working with the community
makes things way easier than under Windows. Ignoring it makes things
way harder. Successful Linux ISVs/IHVs understand this.
It's not that Linux is different, it is that it has far too much inconsistency
at the application API level. Inconsistent in time (too many almost gratuitous
changes over a couple of years, ie. hotplug -> udev -> security kit), and
inconsistent
across distributions (ie. udev files seem to need to be different for each
distribution).
I agree that's partially the nature of the beast, but it also reflects the
priorities and
organization level of the developers - they don't value application vendors so
much
(whether commercial or not), and don't value standardization so much either.
Often
it's lacking vital API's, or they are slow to appear (accessing the VideoLUTs
for each
screen for instance, being able to disable the screen saver etc.) One of the
natural
consequences is that many application vendors stay away.
Graeme Gill.
Other related posts:
